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Introduction 



Electrical distribution systems provide power to loads. Nxomerous individuals 
are involved tn the design, operation, maintenance, zmd modification of these systems. 
Traditionally these individuals have relied on drawings, operations manuals, meter 
readings, and experience as primary resources tn accomplishing these tasks. Emerging 
as a new resource is the Ebq>ert System. 

Expert Systems (E^s) are knowledge based computer programs which provide 
assistance in domain specific problem solving. They solve problems by duplicating 
human problem solving methods using deductive reasoning techniques in conjunction 
with factucd information to analyze a problem and reach a solution. The required 
reasoning skills can be obtained by analyzing the problem solving methods of human 
experts. Factual Information can be organized as individual fact statements or, tn the 
case of large systems, the information can be gathered and organized Into database 
form by DataBase Management Systems (DBMSs). The codification of these reasoning 
techniques and the factual information makes up the knowledge base of an ES. 

The motivation for investigating electrical distribution system ESs comes from 
the potential power of the computerized application of reasoning skills to power 
distribution problems. The present decision to consider ESs can be likened to the need 
to use computer based electronic spreadsheets such as Lotus 1-2-3. Engineers have 
gotten by for a long time doing design cost estimates from a take off sheet with an 
adding machine or calculator. However, with the advent of products such as Lotus 1-2- 
3. engineers have switched in order to realize both Improved speed and accuracy in their 
work. Similarly, the ES offers both speed and multiple solutions while it minimizes 
the possibility of overlooking Information. ESs also have the advantages of 
incorporating the best methods to solve problems, being convenient and availlable (ESs 
don't take vacation or get sick), and always working their best. 

In addition to reasoning abilities, in the electrical distribution setting, the ES 
must access and deal with large amounts of Information. This project supplements the 
ES with a DBMS. The prominent features of the DBMS (optimized data storage, 
retrieval, and manipulation) aid the ES in dealing with the large quantities of 
distribution system Information. 

This thesis demonstrates an ES concerned with electrical distribution system 
connectivity problems. Connectivity concerns the paths for transferring power from 
sources to loads. Using DBMS database information, the ES analyzes how the 
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distribution system provides loads with power. The ES additionally determines the 
efifects of various system faults, such as line failures and the opening of circuit 
breakers. The results of the cmalysis includes determining which loads have lost 
service and which circuit breakers or lines have been rendered unusable. To restore 
power to de-energized loads the ES analyzes the remaining ^stem for possible 
alternative service paths. 

In support of the ES a DBMS manages the information necessary to represent 
the distribution s)^tem and simulate modifications to the system. The DBMS program 
uses the relational model Implementing those essential relational features required for 
this application. 

Chapter 1 discusses the motivation behind this thesis project, defines the ES 
problem area, outlines the joint ES-DBMS solution approach, and provides general 
background information. Through the use of an example distribution system, this 
chapter reviews the nature of the work required of those who memage and maintain the 
distribution system and how they approach their work. This review illustrates the need 
to develop em engineering aid for analyzing system connectivity problems. The chapter 
shows that problem solving techniques can be separated from the facts of a particular 
problem. This separation supports supplementing an ES with a DBMS for problem 
information management. The chapter concludes with background on DBMSs and ESs. 

Chapter 2 examines the DBMS developed in this project. The chapter's emphasis 
is three fold. First, the chapter explains the model used by the DBMS to describe the 
example distribution system. Second, exeimples of DBMS operations provide insight 
Into the power of DBMSs as information managers. Third, this chapter discusses 
program design zmd coding considerations which result from implementing the ES and 
DBMS programs in Borland Turbo Prolog on an IBM AT. 

Chapter 3 discusses the itself. The primary emphasis is on how the ES solves 
problems concerning the delivery of power to loads. Examples that make use of 
distribution ^stem excerpts show the nature of power delivery problems emd the 
approach taken in solving them. This chapter also explains the methodology the ES 
uses to reach solutions by walking through the example problems using pseudo-code 
rules. 

Chapter 4 provides concluding remairks. 
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Chapter 1: Motivation and Background 



Problem Introduction 

This investigation Involves the development of an Expert System (ES) and a 
relational DataBase Management System (DBMS) written tn Borland Turbo Prolog 
(Prolog) to run on an IBM AT. The ES is an engineering aid for analyzing the 
connectivity problems of electrical distribution systems. The DBMS supplements the 
ES as an information manager. 

This study is based on an example distribution system and responds to the needs 
of those who manage and operate this distribution system. This chapter presents the 
example distribution system; introduces the individuals who manage and operate this 
system: and reviews their tasks, resources, and problems. This review establishes that 
the topical area of connectivity analysis is worthwhile and that an approach using an 
ES supplemented by a DBMS is appropriate. The remainder of this chapter Includes 
reasons to support the proposal of an approach composed of an ES supplemented with a 
relational DBMS; a discussion on the general nature of ESs and the Prolog 
implementation; an introduction to relational DBMSs which Includes developing the 
database for the example distribution system: and a discussion of the relationship 
between the ES and DBMS. 

E^xample System 

The example for this work is the electrical distribution system for the Bangor 
Submeirlne Base near Bangor, Washington. The Bangor system is relatively new, less 
than 10 years old. The Bonneville Power Administration (BPA) serves this distribution 
system with a single 1 15 kv feeder. The submarine base distribution system begins with 
a 1 15 kv ring which serves six 1 15/ 12.5 kv substations. The six substations provide 
power to the remaining distribution network. In addition to the 1 15 kv ring feeder, the 
substations can be fed by both permanent emd portable diesel generators. Figure 1 
shows a portion of the system. 
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E^ert S3rstem Users 

In determining the specific nature of an electrical distribution system ES one 
must first answer who will benefit from Its development. Answering the question 
largely means identifying those Involved with the operation, maintenance, design, and 
modification of the Bangor Submarine Base distribution system. 

A small staff of mUltsiry officer- engineers and civil service employees provide 
overall management of the distribution system. Permanent civil service apprentice 
and Journeyman level electricians accomplish dally operations and routine 
mainteneince. Work of a larger nature (alterations, additions. £ind complex 
maintenance) is primarily accomplished through the award of competitively bid 
contracts. With the exception of only the largest contracts, this work is restricted to 
small business contractors. Both staff electricians and contractors perform emergency 
work. Private archltecturzil and engineering (A&E) firms provide engineering designs. 
Civil service staff engineers are charged with reviewing this design work. Management 
of construction and maintenance contracts falls on another oflice. Construction 
contracts are managed by military officer-engineers and civil service engineers. 
Inspectors perform dally quality assurance of contractor work and assist in 
coordinating utility outages. Outside A&E firms may supplement their efforts. 

These groups are potenticil ES users and represent the current human experts. 

Ebcpert System Domain 

The broad group of individuals needing to understand the operation of the 
distribution ^stem are the target ES users. Recent research Into electrical power 
system engineering aids Includes specific areas such as alarm and event message 
processing. Isolation of faulted line sectlons^*2, reactive power and voltage 
management^, and operator training^. The problems of those using the Bangor 
distribution system generally focus on understanding basic system operation and 
possible alternative system operations. Specifically, how does the system now provide 
power to loads, will opening a specific breaker or taking a line out of service adversely 
impact service to any load, and what are the possible recovery configurations for 
veirious fault situations. As distribution ^sterns are generally over designed, system 
connectivity— providing a path from a source to the load— rather than system loading is 
the primary consideration. The issue of system loading and loss minimization through 



efficient loading has been addressed in previous research^. Reviewing the tasks and 
resources of those responsible for the distribution system will show that eUialyztng the 
paths for providing power from sources to loads is a worthwhile ES domeiln. 

Memagers exercise oversight control of the electrical distribution system. Their 
concern is that the system reliably provides loads with required power. Management 
may be made up of architects or engineers of any discipline. They typically do not 
personally seek out detailed technical information. They do. however, need a good 
overall understanding of electrical distribution system operations including the effects 
of various actions on the system. For Instance, managers would need to know if power 
could be provided to an operations building if a given substation or line was taken out of 
service. For these more general questions, they probably already understamd how a 
distribution system generally works or cem familiarize themselves with distribution 
system principles from an elementary text. For how their system works and the 
outcome of a specific question they additionally refer to one line system drawings and 
system operation manuals. 

Staff design engineers and private A&E firms cany out needed project studies or 
designs. A design of any size will involve a project manager and a design team. The 
project manager, like management, may be an architect or any tjqpe of engineer. Project 
managers also primarily concern themselves with overall operational Issues. They 
need to understand the Taig picture* in order to give direction to and provide design team 
co-ordination. A project manager augments his professioned experience emd design 
concepts with project specific information. The design team turns general concepts and 
approaches into project plans and specifications. They too begin with their own 
methods and approaches for doing a particular type design. If they don't have an 
adequate background for a peuticular project they find reference materials— design 
guides, code books, and handbooks— which provide them with the 'how it is done' 
methods. To begin the design they also need a full emd complete knowledge of the 
project system. The design team, using their experience and project specific 
information, develops design alternatives. Each alternative must be tested to ensure it 
works smoothly with the rest of the existing system. Testing may involve amending a 
set of system drawings to reflect the results of the proposed work. The 'new' system can 
then be checked to verily its operation under normal and fault conditions. This step 
must be exhaustive to ensure nothing is overlooked. Considerable design time is 
devoted to getting up to speed with the project system and testing design alternatives. 

Permanent system operators are the most familiar with the distribution 
system's operation. To understand the nature of this experience consider the training 
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of a new operator. The new operator Is first briefed by an experienced foreman. The 
foreman, using a one line drawing, provides a ^stem overview. He discusses general 
system configurations, system capacities, equipment ratings and types. The new 
employee next receives a field tour. Emphasis Is placed on major facilities (substations, 
diesel generators, and large loads) as well as key or troublesome components. While 
training, the operator becomes familiar with system operations and parameters 
through detailed system and component drawings and their manueils. The more 
experienced operators supplement the training with explanations of how 'things are 
done here.’ Eventually the operator has seen most of the equipment zmd ^stem 
operations several times and begins to know how this distribution system works. 

Distribution system operation generally does not require frequent changes in 
the way loads are served. When alternative service paths are required, the design 
usually provides several options. With time, operators learn the best or easiest means 
of serving each load. Operators rely on experience and seldom need to make more than 
slight use of reference materials. On a day to day basis experience proves quite 
satisfactory. EXren If a fault occurs on the system, the operator can refer to Supervisory 
Control and Data Acquisition (SCAD.^ system output, meter Indicators, and field 
inspection to determine the system's faulted condition. Since the system Is operated in 
a limited number of configurations, the operator generally has no difficulty visualizing 
a corrective configuration. 

Unfortunately, when the fault is In an unusual place the operator may stumble. 

If the system is in an unusual configuration to begin with, the operator's experience 
may not offer a solution. Multiple faults can also undermine reliance on experience. At 
times such as these the operator returns to the drawings for specific system 
Information to find power paths for de-energized loads. Since distribution lines are 
normally oversized, line loading Is a secondary concern to finding an available path. 

Maintenance and construction contracts often require the distribution ^stem 
to be placed in unusual configurations in order to accomplish desired work. At these 
times the contract managers, inspectors, and operators need to satisfy themselves that 
the procedures suggested by the contractor or outlined in the contract will work without 
causing a power loss. The proposed operations are aneilyzed being very careful to ensure 
all affects are considered. As contractors. Inspectors, and contract managers tend to be 
the least familiar with the system, the necessary analysis is a time Intensive effort. 

While each of these groups have different motivations for understanding the 
basic operation of the distribution system, they share the need to be able to accurately 
analyze how the system works. This common need Includes a general understanding of 
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how the system serves loads, knowing what results from various ^stem operations, 
and the need to restore de-energized loads in a timely manner. Each person has the 
background knowledge and skills to figure these problems out. They only need to apply 
their problem solving techniques to the particulcu" facts concerning this distribution 
system and the problems needing to be solved. 

The goal of this project's ES Is to assist these users In analyzing normal and 
alternative system operation configurations. This ES determines which of the system's 
lines and loads are energized; Identifies the paths from sources to loads: evaluates the 
effect of opening a circuit breaker--what loads and lines become de-energized: evaluates 
the effect of a faulted circuit breaker or system component— what loads and lines 
become de-energlzed and which are rendered unusable; and provides alternative paths 
for re-energizing de-energized loads. 

Having stated the goal of the ES In serving as a distribution ^stem engineering 
aid, one needs to address why It should. Quite directly, while the current methods of 
finding answers to these problems work, using an ES Is an Improvement. The first 
objection to using an ES might come from the experienced system operator, the human 
expert, who maintains that everything can already be handled quite nicely without any 
assistance. Take for Instance, however, the problem of Identifying what happens when 
a given breaker Is opened. Anyone familiar with distribution systems would consider 
this problem routine and straight forward. They would have a methodology for 
determining which lines and loads were de-energized when the breaker opened. They 
would then need to apply their problem solving method to the particular facts of this 
problem. The experienced operator may not even need to refer to any drawings for 
additional information before completing his solution. Of course. In his haste he might 
overlook something. Others would need more time and reference material. Each would 
probably reach a solution to the problem. This simple example points out that not all 
users (or experts) have the same ^stem knowledge and experience or proficiency at 
problem solving. By encoding the experts' problem reasoning methods and the ^stem 
information into an ES knowledge base to take advantage of computerized reasoning 
these types of problems are more quickly solved while ensuring nothing Is overlooked 
and all possible solutions cu*e discovered. Reducing the time required to solve problems 
and improving the quality of the solution by ensuring Its accuracy and completeness 
answers why this fype ES should be used. 

In reviewing the needs of the various potential user groups. It becomes apparent 
that system operators' needs are somewhat different from the other groups. In their 
case, the SCADA provides on-line sensing of the system’s conditions including what 
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loads cire being served. They need an ES that recognizes faults and problems and then 
determines solutions to the fault problems. The other groups can be characterized as 
off-line users. They use Information that represents what the SCADA provides and 
want to run *what If drills on the system. In this case the ES needs to determine the 
effects of system operations instead of sensing them as In the on-line case. Since the 
off-line case eliminates the need to consider the SCADA-DBMS Interface and since the 
off-line users are the target group most likely to embrace an ES as an aid, the off-line 
needs are examined In this thesis. The ES serves as an off-line engineering aid in 
analyzing distribution system connectivity problems. 

An Expert System and DataBase Management System Approach 

This project supplements the ES with a DBMS. The DBMS acts as the source of 
system specific Information and as an information manager. Specifically, the DBMS 
provides the ES with database information describing the distribution system and the 
ability to modify that information. This chapter discusses the general features of any 
relational DBMS. Chapter 2 Illustrates specific Information management techniques 
by demonstrating some relational operations using the DBMS written In Prolog to 
support the E^. 

There are two reasons for using a DBMS In this way. First, DBMSs are 
particularly efficient at storing, manipulating, and retrieving information. Second, 
efficient management of information eu-gues for a centralized. Independent data 
management system for use by application programs. 

The first reason for using a DBMS concerns utilizing Its data management 
strengths. The goal for the DBMS written In this project was to include those DBMS 
features which most characterize a relational DBMS In so far as they could be 
reasonably implemented In Prolog and were necessary In the ES companion role. 
These features include: offering a means of entering Information which describes the 
system: the capability to add to, delete, or change that Information; and the ability to 
take Information In one form and change it Into cinother. 

In an on-line version of this project's ES, the SCADA's Information about line 
loading, load requirements, and breaker positions would interface to the DBMS. A 
DBMS routine could tcike raw data, condition it, and store it as database information. 
This information would then be avsitlable to the ES. For the off-fine version of the ES 
the data Is manually entered into the DBMS fir its 'natural' form. In addition to storing 
information which describes the distribution system, the DBMS can be used to describe 



10 

modifications to the system. As an example, a contractor can determine how taking 
several lines out of service affects ^stem operation by deleting the database records 
that represent those lines emd then having the EIS evaluate the amended database. 

The second reason for using a DBMS Is the argument that data should be 
managed separately from applications that mcike use of It. From the discussion 
concerning what distribution system work was done and how people went about doing 
It, one could see that people applied their own problem solving techniques to the facts of 
a specific problem. These examples Illustrate the Idea of separating the application 
program (problem solving technique) and data Itself (the specific problem). These 
examples support the argument that a problem solving technique Is largely 
mdependent of the specific information of any given problem. 

With this approach the ES serves as the codification of the ways people solve 
distribution system problems without carrying with It the information about that 
given distribution system. One practical advzmtage of keeping system specific data 
separate from the ES Is that the ES then becomes much more mobile. The same ES 
could be used with other distribution ^sterns without extensive modifications. The 
DBMS then provides problem specific information and general information 
management support. For a simple problem with limited Information this separation 
may not seem significant. However, as ESs take on larger systems, the amount of data 
involved becomes quite significant, so could the advantages gained from using a DBMS. 

Bixpert Systems and Prolog 

This section discusses the general nature of Expert Systems (ESs) and 
Implementing them In Prolog. ESs are computer programs which, by reproducing the 
methods used by human experts, provide assistance in domain specific problem 
solving. Domain specific problem solving means the ES concentrates on solving 
problems in a single topical or functional area. This ES’s domain Is connectivity 
within an electrical distribution system. Providing assistance may mean faster 
solutions, being able to consider larger systems or more complex problems, or simply 
not overlooking any of the problem facts or solutions. 

To solve any problem zm ES must apply the human expert's problem solving 
know-how to the facts of the problem. E^xpert know-how Includes formulas, 
relationships, procedures, and Instincts in the form of reasoning rules. These rules and 
the problem facts are codified to form the ES’s knowledge base. The ES’s inference 
engine then applies appropriate rules to the available facts to reach problem solutions. 



1 1 

As ein ES is a computer program, the knowledge base and inference engine must 
be encoded in a computer language. Traditional programming languages handle 
encoding of facts without any problem. For example, to encode the maximum current 
capacity of a specific line, programmers can use a variable assignment such as 
Une_current(Ll 14Z)=7000. However, encoding the other half of the knowledge base, the 
reasoning rules, traditional programming languages do not handle weU. The difficulty 
arises from traditional computer languages emphasizing variable assignment and 
program control. They specify how variables eire updated and used based on other 
variables using an essentially sequential program control. The programmer 
concentrates on describing a rigid control sequence of how the program (and variable 
assignments) will be carried out. What is being calculated though is usually implicit.® 
These languages are described as imperative for they give commands and direction. 

This programming method does not readily duplicate human reasoning. 

A recent class of programming languages is non-imperative or declcirative. 

Their emphasis is not on how the program is executed but rather on describing what is 
being evaluated or calculated. These declarative lemguages include LISP. OPS83, and 
Prolog. Borland Turbo Prolog (Prolog) was selected to Implement both the ES and the 
DBMS. There were two primary reasons for this selection. First, Prolog which stands 
for Prog ramming in Log ic, uses a predicate calculus rather than depending on 
sequential instructions. The predicates form conditional 'if-then' rules which allow 
Prolog to deduce or infer new facts from other facts. This ability to Infer conclusions 
from other information is a characteristic of human reasoning. Second, the task of 
integrating the various knowledge base rules and facts to reach a conclusion is taken 
care of in Prolog. Prolog does the integration with its built-in inference engine. These 
features make Prolog a good candidate for modeling this type of human reasoning. 

A general discussion of Prolog programming follows. A full treatment of 
standard Prolog is given by Clocksln and MeUlsh^. Borland Turbo Prolog is a superset 
of standard Prolog and is described in various publications as well as its 
manufacturer's manual®. 

Prolog programs are based on an application of predicate calculus. Predicate 
calculus or propositional logic is built around the use of predicates. Predicates are 
functions which return either a true or false value when evaluated. A predicate 
evaluates true only if its argument variables are substantiated or matched with known 
values. The simplest Prolog program contains a 'predicates' and a 'clauses' sections. 

The 'predicates' section simply declares the predicates to be used in the clauses 
section. A predicate expresses the relationship between the information of its 
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aigtiments. It has a name and an ordered set of arguments or attributes. The synteix of a 
predicate Is ’name(al,a2.a3)'. As an example, the predicate 

’bkr_lnfo(name. position, rating)' maintains Information concerning a breaker's 
name. Its present position, and Its Instantaneous current rating. 

The program's clauses section consists of fact clauses and rule clauses. Upon 
program execution these are active In RAM and become part of the progreun's working 
memory. A fact clause Is merely a single Instance of a predicate. For example, for the 
predicate bkr_lnfo(name, position, rating), bkr_tnfo("SDlA","open", 10000) Is a single 
fact clause. E^ch fact clause can be likened to a database record. Rule clauses take 
Individual predicates and form them Into conditional If-then statements. 

Rules are used to reach implicit facts or conclusions. In Prolog the form of the 
rule is 'A IF B' or, stated in 'If then' form, 'IF B THEN A.' The rule can be viewed as two 
parts— the left hand side, LHS, and the right hand side, RHS. The LHS of the clause acts 
as the current goal trying to be satisfied. The RHS is a combination of predicates which 
make up the conditions or subgoals necessary to satisfy the LHS. For example, the 
following rule determines the position and raring of a breaker. 

bkr_lnfo (Breaker, Position, Rating) if 

bkr_posltlon(Breaker, Position) zmd 
bkr_rating(Breaker, Rating). 

If the program were trying to determine the position and rating of the breaker SDIA the 
goal bkr_tnfo("SD lA", Position, Rating) would Invoke this rule. For this rule to 
evaluate true, clause facts must exist or be deduced for bkr_posltlon("SDlA", Position) 
and bkr_ratlng("SDlA",Ratlng). Each of these RHS predicates become subgoals of the 
rule. The subgoals are satisfied If veilues are matched or 'bound' to the variables 
'Position' and 'Rating.' Values bound to RHS predicate variables also become bound to 
the same variables in the LHS of the rule. Once the LHS is satisfied by the binding of 
values for SD LA's rating and position, an Implicit fact Is established and the rule 
returns true. If either of the subgoals bkr_posltlon("SD 1 A", Position) or 
bkr_raUng("SDlA", Rating) are not substantiated, the LHS is not satisfied and so the 
rule returns false. Hence, Prolog relies on If-then rules to reach conclusions. 

The Prolog programmer concentrates on the relationships the rules represent. 
Consider the case where the method of calculating delivered power is dependent on 
system configuration. There might be six different configurations to consider. Each 
system configuration would require its own power calculation formula. In Prolog, the 
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six configurations and calculation methods would require six rules. In addition to one 
of the power formulas, the RHS of each rule would Include the predicates necessary to 
uniquely determine the system configuration appropriate for that power calculation 
formula. Other than Including those conditions necessary for using any given rule, the 
programmer provides no program direction as to when the program goes to or uses any 
one rule. In execution Prolog handles the details of matching the situation (facts) of 
each configuration to the power calculation formula. In this way the programmer 
concentrates on describing how the LHS of the rule Is satisfied by the combination of 
RHS predicates. 

The whole set of rules along with any clause facts make up the clauses section. 
Program execution is begun with a user question (goal) In the form of a predicate. 

Prolog then selects rules which are appropriate for satisfying the goal or subgoal being 
pursued. 

The implicit facts developed in satisfying a goal or subgoal are transitory in 
nature. Unless made part of the working memory, the facts developed exist only while 
attempting to satisfy the subgoal. To support the need to make deduced facts permanent 
and likewise remove facts no longer true. Prolog supports a dynamic database. This 
feature allows the program to have permanent rules, permanent facts, and dynamic 
facts In working memory. 

The command 'assert' places facts into the dynamic database. The command 
'retract' removes facts from the dynamic database. Predicates for the dynamic database 
are declared in the 'database' section. These predicates, just like regular predicates, are 
used as part of rules within the clauses section. To become facts within working 
memory, however, the program must take positive action and 'assert' a database 
predicate, with Its given set of argument values. Into the dynamic database as a fact. 
When a given fact Is no longer needed or Is no longer true, the program takes positive 
action to 'retract' the clause fact from the d)mamlc database. 

The distribution system ES consists of a distribution system knowledge base. 
Prolog's built-in Inference engine, and a querying Interface. The distribution system 
knowledge base consists of If-then rules representing the ways distribution system 
experts step through solving various problems and predicate clause facts representing 
distribution sj^tem Information. A querjdng interface allows the user to submit 
questions (goals) which the inference engine attempts to answer using the knowledge 
base Information. 
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DataBase Management Systems 

The Inclusion of a DBMS as part of an ES is based on its data management power 
and convenience as a central data source. Most engineers are comfortable with the 
concept and use of databases. The DBMS as a program which works with databases is 
also a comfortable idea. Most, however, have only a fuzzy feeling for the full 
capabilities of DBMSs. The purpose of this section is to give some clarity to the notion 
of a DBMS, particularly the relational model DBMS, and, in doing so, to further develop 
the distribution system model. The convenience of using a DBMS as a data source 
should also become clear. For a complete treatment of the DBMS topic refer to a text on 
the subject.^ 

A design engineer may decide he needs some organized method of keeping track 
of all the possible circuit breaker types used in distribution system design. He could 
develop a ’distrlbution_breakers' Information table consisting of rows and columns. 
Each row acts as a record of information for a particular circuit breaker type. Each 
column stores information about some attribute of the circuit breeiker. In this example 
the following might make up three records from the database: 



type breaker 


voltage 


max current 


type relay 


lxas2 


12.5 


100,000 


c 


lxas3 


12.5 


250,000 


b 


2xas3 


7.5 


75,000 


a 



His entire table would consist of all the records made up in this form. A database 
program would include the functions necessary for entering, modifying, and retrieving 
records from this table. 

A DBMS, however, consists of much more. A DBMS is a program composed of 
those procedures necessary to facilitate database creation; data input, storage, and 
retrieval; and database manipulation. The power of database manipulation is what 
most characterizes DBMSs. 

The power and flexibility in making database mcinipulation operations depends 
on the data model. While data can be modeled in several ways, the relational model is 
considered by many to best achieve the needs of maximizing flexibility while retaining 
manipulative power. Most DBMS models treat the relationship among record data 
similarly, as an ordered set of attributes. In the relational model, the entire set of 
records (the table) is called a relation. All the relations on a particular subject, the 
distribution system for example, make up the database. What further differentiates 
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data models is how they handle connections between relations. In the relational model 
there is no fixed connection between relations. The lack of any fixed connection 
between the relations allows the information within the database to be reorganized as 
desired to form new relations using attributes common between relations. 

For an engineer, the relational DBMS serves as follows: 

-1) provides Information In a user understandable form: 

-2) provides information In Its most basic and Independent form; 

-3) maintains database consistency and integrity: 

-4) provides Informational tools useful In problem resolution. 10 

Information in a User Understandable Form 

Effective use of any system requires that the user understand the system's 
organizational model and be willing to work with that system. So It Is with DBMSs. 

The user must be able to organize his data in an easily understood form. Relational 
databases organize information In tabular form. As with other database models, each 
row Is a record. A record holds a set of related attribute values. E^ach column of the 
table stores a particular attribute of the table. As an illustrative example, consider the 
relation BRANCH modeling the topology of the Bangor submarine base substation # 1 
shown In part as figure 2. Table 1 shows the relation for this figure’s topology. As with 
other models the columns represent relational attributes— node field, element field, and 
via field. Each row is a relation entry. Each entry within the relation Is unique. 






MSXl 

SDMSXl 

NS3 



Figure 2. Substation #1, in Part 
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Table 1. BRANCH delation for Substation #1 

attributes: node field, element field, via field 



entry #1 nsl, 

entry #2 ns2, 

entry #3 ns3, 

entry #4 ns4, 

entry #5 ns5, 

entry #6 ns4, 

entry #7 nsl, 

entry #8 ns2, 

entry #9 ns3, 

entry #10 ns5. 



subl, 

subl, 

subl, 

subl, 

subl, 

LI 14, 

B30, 

Tl, 

MSXl, 
LI 15, 



none 

none 

none 

none 

none 



SD114 

SD30 

SDTl 



SDMSXl 

SD115 



Information in its Most Basic and Independent Form 

While these relations can be developed in £iny manner, data Independence 
requires that the relation be based on the data’s natural relationships rather than any 
specific application. If one were developing a database to support a specific application 
it may seem more reasonable to model the system and data management toward that 
specific application. That might be cm acceptable approach under certain conditions. 
These conditions would Include being sure that the nature of the application will not 
change emd require that the data be cheinged; that the data being collected for this 
application is not already available elsewhere or similarly needed elsewhere; and that 
the results of the application program using this data are not of Interest beyond the 
application program's purpose. Unfortunately these conditions seldom exist. 

Computer software by its very nature changes. It either does not do exactly what was 
really required or does it so well that more is desired. Concerning whether the source 
data is available or needed elsewhere, the very nature of large engineering systems or 
information systems of amy type tend to make Information common to several 
applications. Similarly, when an application program uses Information to perform its 
task it is likely that the program's resultant Information may be of use to other 
systems. Having data In its most basic amd independent form enables the data to be 
elTiciently shared between applications as well as allowing for the maitntenance of 
database consistency and integrity (discussed below). The process of obtaining, storing, 
amd manipulating information for use by applications is what DBMSs are all about. 
The current 'state of the art' for structuring data in its principal independent form is 
"fourth normal form" (FNF) normalization^ 1. Developing distribution system 
relations begins by describing this system’s topology. Figure 3 represents a typical 
portion of the system. The system's topology is modeled as a set of cormected branch 
elements. The branch element end points au'e labeled as nodes. Note that loads only 
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have a single endpoint cind that each load branch has a switching device associated 
with it. 



SDPIC SD5096 




Load 



Lines 



Nodes 



Figure 4 shows a tjTJlCcil line branch element pulled out of the system's drawing. In any 
relation, certain attributes are considered key attributes. The key attribute fields 
uniquely identify a specific relation entry. To represent the distribution’s system 
topology In FNF, the branch element of figure 4 must be characterized by one or more 
key attributes so that each unique combination of key attribute values matches up with 
only a single set of remaining attribute values. 






-Llne/Network 
Seqment 

dpoint 

— — ^Switching Device 

Figure 4. Typic^ Line Branch Element 



Figure 5 shows the previous line segment represented as two 'one end point' segments. 
When viewed In this way, each of the 'one end point’ segments can be uniquely 
identified by two of its three characterlstics-segment name, endpoint name, or 
switching device name. Segment name and endpoint name are used as the key field 
attributes which uniquely describe the switching device attribute. The notation for 
segment name and endpoint name being key field attributes describing the switching 



device attribute Is: 



1 8 

( endpoint neune, field segment name-> switching device). 

In the case where there is no switching device the attribute value is filled in by the word 
'none'. Table 2 illustrates this relation, BRANCH, describing the topology of figure 3. 



r\_# 



Figure 5. Typical One l^d Point Line Segments 



attributes: 



Table 2. BRANCH Relation for Figure 3. Typical System Portion 

endpoint name field segment name switching device 



N1.2, B5096, SD5096 

Nl.O, LSPIC, none 

N1.2, LSPIC, SDPIC 

Nl.O, L114z, none 

N1.7, L114z, none 

N1.7, L114y, none 

N1.8, L114y, none 



As a more complex example, table 3 illustrates this relation describing the topology of 
substation #1 as shown in figure 2. In this example both key attribute fields are 



required to uniquely identify various line segments. 



attributes: 



Table 3. BRANCH Relation for Figure 6. Substation #1 

endpoint name field segment name switching device 



nsl. 


subl 


ns2. 


subl. 


ns3. 


subl. 


ns4. 


subl. 


ns5. 


subl. 


ns4. 


LI 14, 


ns2. 


Tl. 


ns3. 


MSXl, 


ns5. 


L115. 


nsl. 


B30, 



none 

none 

none 

none 

none 

SD114 

SDTl 

SDMSX 

SD115 

SD30 



For the two other relations, BDESC and BKRPOS, are needed. BDESC stands 
for branch description and is described by: 

(element -> type, rating). 

'Element' refers to the branch element's name. Type' refers to the element's type— load, 
line, or source. The 'rating' attribute serves to store the line's or source's maximum 
capacity and the load's maximum load value. Table 4 lists the BDESC records for that 
portion of the system Illustrated In figure 2, substation #1. 
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Table 4. BDESC Relation Records for Substation #1 



attributes: element type rating 

subl. source. 8E6 

LI 14. line. 1E6 

Tl. line. 1E8 

MSXl. line. 1E8 

LI 15. line. 1E6 

B30. load. 30 



BKRPOS represents breaker position. BKRPOS relates each switching device to its 
current position: 

(breaker -> position). 

■Breaker’ stores the switching device's (breaker’s) name. The breaker’s position is stored 
in ’position'. Table 5 lists the BKRPOS records for that portion of the ^stem Illustrated 
In figure 2. substation #1. 



Table 5. BKRPOS Relation Records for Substation #1 



attributes: breaker position 

SD30. closed 

SDTl. closed 

SDMSXl. open 

SD114. closed 

SD115. closed 



The description of the distribution system is limited to these three relations as they 
adequately serve to demonstrate the DBMS and contain the information required by 
the expert system. 

Database Consistency and Integrity 

The consequence of maintaining data In FNF is that data is In its natural form 
rather than project specific form. Any given user of the database begins with the same 
fundamental Information. The FNF format allows the DBMS to configure or structure 
database information as required for use by any specific application. This form avoids 
unnecessary file duplication and updating problems. 

FNF also promotes database consistency and Integrity. By assuring that data is 
maintained in its most basic form, without duplication within the database, every user 
will get the same data values. Avoiding duplication of data and urmecessary data 
dependencies also helps control database Integrity. Completeness and soundness In the 
database is the result of a well understood and easily maintained configuration. 

Informational Tools for Problem Resolution 

DBMSs mcinlpulation strengths provide the engineer with an environment 
useful for engineering problem resolution. By querying the database, access to required 
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Information Is obtained from much larger pools of information. The basic relations 
can be Joined together to create new relations through powerful manipulative 
capabilities, relational algebra. 

Database manipulation consists of both operations within a single relation and 
operations between two relations. Eixamples of database mcinlpulation features 
Include; querying the relation based on selection criteria and forming a new relation 
from an existing single relation or from two existing relations. 

As an example of joining two relations together to form a third, consider the 



following records: 
relaUon BRANCH 


attributes: 


node field. 


element field. 


via field 




n2.39 


bmhS 


sdmhS 




n2.39 


bl014 


sdl014c 




n2.39 


blOlS 


SdlOlSc 


relation BKRPOS 


attributes: via field, 

sdlOlSc 

sdl014c 

sdmhSb 

relation BRANCHOPEN 


position field 

closed 

closed 

open 




attributes: 


via field. 


element field. 


position field 




sdmhSb 


bmh8 


open 




8dl014c 


blOlS 


closed 




sdlOlSc 


blOlS 


closed 



The first two databases act as the source databases. The third database results from 
Joining the first two. As shown, both contain the attribute Via field' which stores 
Information concerning circuit breakers Those records with common 'via field' values 
(shown In bold type) serve as data sources for the new database record. The third 
database contains this common field as well as the 'element field' taken from the first 
database, and the 'position field' taken from the second database. 

In this example the BRANCH and BKRPOS relations were Joined together using 
the common attribute called 'via field' to form a new relation BRANCHOPEN, The new 
relation conteilns the database Information concerning which element each breaker Is 
associated with and the present position of each breaker. In general, in the relational 
model DBMS, relations can be Joined using any or all of their common attribute fields. 



ES Working With a DBMS 
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This paper proposes that an and a DBMS work together as a distribution 
system engineering aid. The DBMS supplements the ES by acting as its source for 
information about the distribution system. The ES takes this information and 
together with its rules solves problems concerning system coimectlvlty. 

For the ES to solve these problems it needs to know about: system topology— how 
the system branch elements are connected together; the function of each ^stem 
element— does it use power (a load), transmit power (a line), or provide power (a source); 
and the status of system elements— are circuit brecikers and switching devices open or 
closed. This is the information required from the DBMS. 

How does the DBMS get this Information? Some of the Information, system 
topology and any element's function, is static. Static information can be manually 
entered into the DBMS one time as the relations BRANCH and BDESC. The position of 
system switching devices is not static. The SCADA system can provide this 
Information. In the case of an on-line ES there would need to be a hardware/ software 
interface between the SCADA and the DBMS. This project, however, considers the off- 
line user. For their purposes there is a set of data for the 'normal position' of all devices. 
The relation concerning switching device positions is BKRPOS. 

These relations comprise the database Information for the ES. From this 
Information the ES determines the system's initial conditions. Should the user desire 
to begin with a non-normal Initial configuration, one modifies the original input 
relations by using the DBMS. Using the DBMS is necessary when testing design 
alternatives which require modifying existing topology. Alternatively, the user can 
input the normal configuration and interactively, with the ES. test system response by 
opening switches or removing lines. The interactive mode Is oriented to considering 
system faults. 

The ES requires only paut of the information contained in the distribution 
system database and it requires it In a different form. The ES uses a single relation, 
BINFO. The format of BINFO is; 

(node, branch -> type, breaker, position). 

For BINFO the FNF is abandoned in preference of a relation structure more suitable for 
the needs of the ES application. The ES calls upon a relation preparation program to 
perform the necessary relation manipulations and data format conversion to prepare 
an ES compatible BINFO relation. Appendix A discusses other general methods of, and 
obstacles In. linking an ES with a DBMS. 
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Chapter IL The Data Base Management System 



DBMS Introduction 



This chapter deeds with the DBMS developed as part of this thesis project. It Is a 
relational model DBMS written In Prolog. In order to develop further appreciation of 
the potential of a DBMS as a data manager and engineering tool, this chapter discusses 
the Implemented DBMS features and gives examples of how they perform. Emphasis Is 
also given to the Prolog Implementation and program design considerations. 

Ebcamlning the Prolog code concerning Its rules and facts provides addltlonad Insight 
Into the nature and flexibility of the programming language. 

Motivatloii for Prolog Implementation 

The motivation In developing a Prolog Implemented relational DBMS was 
having a DBMS whose structure and code were well understood and available for use as 
a companion to the ES. This enhanced the joint use of the and DBMS by permitting 

the development of a relation preparation program. The relation preparation program 
performs the necessary manipulations of the FNF distribution system relations to 
reorganize the database Information Into a relation specifically for the ES. 

Relation Data Base Management S3rstem Overview 

The goal for the Prolog DBMS was to Included those DBMS features which most 
characterize a relational DBMS In so far as they could be reasonably Implemented In 
Prolog and were necessary in the companion role. The DBMS was developed without 
further consideration of Its role as a ES companion. This approach preserves the basic 
goal of treating data In its most natural form under the premise that Information 
should be managed on its own merits and not that of the tcirget application. 
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The basic relational DBMS features included is this project's DBMS are: 
friendly user Interface; 
basic help information: 
creating new relations: 

selecting an existing relation for manipulation; 

entering records into the selected relation; 

viewing relations in whole or based on selection criterion; 

modifying existing records: 

projecting a new relation from an existing one: 

joining two relations to form a new relation. 

The user interface refers to how the user directs the program to execute commands. A 
simple DBMS uses menus to lead the user though the necessary steps in specifying 
commands. While the use of menus is very ea^ it is also slow and becomes cumbersome 
as one gains proficiency. More sophisticated DBMSs use a simple natural querying 
language. Commercial DBMSs integrate these two approaches so that novice users can 
rely on menus while learning and have benefit of the speedier querying language when 
the DBMS is mastered. Help information varies in both method of access and degree of 
detail. The remaining listed functions concern relation manipulation. 

These relation manipulation features are selected through the user interface. 

The DBMS being demonstrated here does not attempt to duplicate all the relational 
operations found in full featured commercial products. It does, however, try to 
Implement the select, project, and join operations. 

In addition to the previously mentioned features the following additional 
features exist: 

directory information concerning available databases; 
an erase function for removing database clauses from RAM; 
an information window indicating the active relation: and 
a time and date display. 

User Interface and Command Overview 

The user Interface adopted attempts a compromise position between the menu 
and query language approach. A direct query language approach is used for general 
progrcim direction. It is felt that a user would quickly become familiar with this part of 
the program's operation and would benefit from the directness of a query language more 
than the aid of a menu ^stem. Some of the more complex relational operations use a 
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prompting menu-like approach. A prompting approach recognizes that the user Is 
likely to need more assistance with these operations. Prompting also avoids the 
necessity of complex query language pcU"slng (decoding of more complex query language 
commands) or requiring a rigid pattern of simpler direct language commands. This 
section Illustrates the query language by showing its use in Invoking the basic program 
functions. In doing so this section also provides an overview of the Implemented 
program functions. Appendix C contains a further summary of DBMS commands. 

The DBMS uses ke)word phrases for program direction. These may be of two 
forms— long and short. An 'action' word and 'object' phrase comprise the first or long 
form. The action word is the function to be performed by the DBMS. The object phrase 
indicates the flies being operated upon. For example, 'enter rl' directs the program to 
enter records in the relation rl. The second or short form uses only the action word. 

For example, 'enter' would direct entering new records into the current relation. Should 
there not be a current relation, an error message would result requiring a relation to be 
selected. Some desired actions such as 'join rl r2 r3' for joining relations rl and r2 to 
form r3 have no short form. 

The short command 'help' triggers a help Information screen In the primary 
window. This screen provides a concise listing of program functions. Additionally, the 
key action word accompanies each program function description. 

In creating any relation the first action involves defining the relation. The 
action word 'new' and object phrase 'name' triggers this function. For example, 'new 
bkrposa' begins creating a relation called BKRPOSA. Note that only single word 
alphabetic names are supported. The actual defining of the relation Involves naming 
the fields followed by assigning field types and lengths. 

At this point the relation BKRPOSA Is the active relation. Should the user desire 
to select a different relation for use. the command 'select' would be used. Should the 
select command be used alone, without an object phrase, the relation BKRPOSA as the 
last active relation is automatically assigned as the object phrase. In order to switch to 
a new relation that relation's name would be used as the object phrase. An example of 
switching to the relation BRANCH would be 'select branch.' 

Once the appropriate relation has been selected the user is ready to manipulate 
that relation. The manipulation commands Involving a single relation include: enter; 
view; modify; and project. To enter new records the short command is 'enter' while the 
long command is 'enter branch.' Using the long form of the command avoids the need to 
use the 'select' command. The program uses the field's name. type, and length as the 
field input prompts. 
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In viewing records, the user may choose between viewing all the records within 
the relation or onfy selected records. The short forms for this feature are View all' and 
View select’. Examples of the long forms are View all bkrpos’ and 'view select bkrpos’. 
Again one can switch relations directly by specifying a new relation as the last portion 
of the object phrase. The 'view all' option lists aU records in the order they were entered 
and stored in the relation datafile. The 'view select' operation is an example of the 
DBMS using a prompting mode for command input. The 'view select' option first causes 
each field of the relation definition to be sequentially listed. As each field is listed the 
user can input the desired matching field criteria or use a the wildcard character, to 
indicate no specific matching criteria. 

The 'modify' command allows for changing existing records. The command's 
short form is ’modify’ and its long form is 'modify branch.' The records to be modified 
are found based on modification selection criteria. As with the view command, the user 
Indicates which fields have specific selection criteria and which fields have no 
selection criteria. In a similar manner the user Indicates what the new or replacement 
data is. 

Once the basis for determining which records are subject to modification and 
the nature of the replacement data is complete, the user chooses one of the four 
modification modes. They are: 

global change with no further prompting: 
global change with individual record prompting; 
delete records with no prompting: 

Individual record changes. 

In the individual record change mode the user may use either the standard replacement 
data or alter the new data for each record found for modification. 

The form of the 'project' command Is 'project rl r2’. This function takes relation 
rl and 'projects' it into r2. Projecting Involves moving aU or selected fields from the 
original relation into a new relation. Additionally either all records or only records 
meeting specified selection criteria may be passed to the new relation. The 'project' 
command automatically takes care of defining the new relation format file. This 
command has no short form. A detailed example of using the project command to 
determine aU open switching devices Is provided later in this chapter. 

The 'join' command works on two relations to form a new third relation. It too 
only has a long form. The command 'join rl r2 r3' takes relations rl and r2 to form r3. 
Like project, aU or only selected fields and all or selected records can be passed to the 
new relation. The key to the join command is specifying fields and selection criteria 
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which must be common to both the original relations. Using this command simple 
relations can be combined Into more complex relations. For example, the BRANCH and 
BKRPOS relations could be merged Into a new relation ’BRCHOPEN’ when needing to 
determine those branches which contain open switches. This result Is possible because 
the BRANCH relation contains the information concerning the relationship between 
switches and branches and the BKRPOS relation knows which devices are open. 
Performing a logical 'and' on these relations creates the desired new relation. Later In 
this chapter this example Is examined In detail. 

These data manipulation functions are the primary features of this DBMS. 

Coding Overview 

This section concerns aspects of Implementing a relational DBMS In Borland 
Turbo Prolog on an IBM AT. Key concepts of a relational DBMS Include the relational 
model and relational manipulation. This section presents the method for storing the 
relation In RAM and on disk. How the true-false evaluation of predicates Is structured 
to achieve program control and thereby direct relational manipulation Is discussed. 
The last Issue presented, relational manipulation methods, concerns trade-offs 
between manipulation speed and maximum relation size. 

Relation Structure 



A relational DBMS views any relation as a table of ordered attributes. Table 6 
shows that part of the relation BRANCH which represents substation # 1 as shown In 
figure 2. 



Table 6. FNF Relation BRANCH to Substation #1 



endpoint. 


field segment 


switching device 


nsl. 


subl 


none 


ns2. 


subl. 


none 


ns3. 


subl. 


none 


ns4. 


subl. 


none 


ns5. 


subl. 


none 


ns4. 


LI 14, 


SD114 


ns2. 


Tl, 


SDTl 


ns3. 


MSXl, 


SDMSX 


ns5. 


LI 15, 


SD115 


nsl. 


B30, 


SD30 
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Prolog recognizes a predicate whose arguments all have specific values, a predicate 
clause fact, as factual Information. For the relation BRANCH the comparative 
predicate Is: 

branch(segment_ncime, node_name, swltchlng_devlce_name). 

Table 7 lists the Information of table 6 expressed as Prolog facts. 



Table?. 

branch(endpoint, 

branchC'nsl", 

branch("ns2", 

branch("ns3", 

branch("ns4", 

branchC’nsS", 

branch("ns4", 

branch("ns2", 

branch("ns3", 

branch("ns5", 

branch("nsl". 



Prolog Clause Facts for Substation #1 



field segment, 
"subl", 

"subl", 

"subl", 

"subl", 

"subl", 

"LI 14", 

•Ti", 

"MSXl", 

"LI 15". 

"B30", 



switching device) 
"none") 

"none") 

"none") 

"none") 

"none") 

"SD114") 

"SDTl") 

"SDMSX") 

"SD115") 

"SD30") 



The prolog predicate "branch' serves as the means for storing the information In the 
relation BRANCH. The user sees only the relation's Information and not the actual 
method of storage. The DBMS uses the dynamic database feature to facilitate 
transferring from the table model of the relation to a Prolog model using predicate 
clause facts as database records. 

For a predicate to be part of the dynamic database it must be declared In the 
database declaration section. The declaration requirement presents a problem for a 
general purpose DBMS. For specific Prolog applications the predicate 
branch(segment_name, node_name, swltchlng_devlce_name) would be listed within 
the database declaration section. This approach Is unworkable in a general purpose 
DBMS as the relations are unknown to the programmer. The programmer needs a 
standard database declaration which will facilitate whatever relations are later 
defined. The form of the database records Is consistent though. As each record consists 
of a set or list of attribute values and is associated with a specific relation name, the 
format can be generalized to dbase(relatIon_name, datajlst). This format provides 
each database record with the Prolog database predicate 'dbase' and two arguments. The 
first, relation name, links the record data to the correct relation. The second, data list. 
Is a list which contains the attribute values. 

Using a list to hold the attribute values solves the problem of being able to 
support a random number of attributes in each relation. Because Prolog, during 
program execution, dynamically handles list sizing the number of elements In the list 
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is unspecified. However, this version of Prolog doesn't support mixed domain lists. As 
such, each element of the data list must be of the same domain. In the database section 
of the program code, the predicate is declared as dbase(strlng, dllst). The argument 
'relation name' must be of standard type 'string' and the data list must be of the user 
defined type 'dllst.' Since this DBMS considers three data types, string; Integer; and 
real, the domain type 'dllst' must accommodate each type. To allow mixed data within 
the dllst argument, dllst is declared as 'a_fleld*', a list of t)^e 'a_field.' A_field is 
defined as s(strlng) or i(strtng) or rfstring). Dllst represents a list of data functored 
tokens. The first letter of each functor indicates the data type it represents and the 
ai;gument the actual information. As the argument to each functor is of type string, the 
actual Information is converted to string for storage purposes. This arrcingement 
handles accommodating the relation as database records within RAM. 

Database File Structure 



As a superset of standard Prolog this version of Prolog supports storing database 
information on disk. In storing Information on disk Prolog treats each fact clause as a 
single term. This results in the whole clause being written or read. Table 8 illustrates 
the same information shown in tables 6 and 7 as 'dbase' predicates. Prolog uses the 
same format both in RAM and on disk. This format results in a flat ASCII fUe. 



Table 8. BRANCH Database File Sample 



dbaseC'BRANCH", [s( "ns 1 
dbase("BRANCH", |s("ns2 
dbase(”BRANCH",(s("ns3 
dbase("BRANCH",[s("ns4 
dbaseC'BRANCH", [s("ns5 
dbaseCBRANCH", [s("ns4 
dbase("BRANCH",[s("ns2 
dbaseC'BRANCH", IsC'nsS 
dbase("BRANCH",(s("ns5 
dbase("BRANCH",(s("nsl 



"),s("subl 


"),s("none 


")]) 


"),s("subl 


"),s("none 


")D 


"),s("subl 


"),s("none 


")1) 


"),s("subl 


"),s("none 


”)1) 


"),s("subl 


"),s("none 


")D 


"),s("Ll 14 


"),s("SD114 


")D 


").s('Tl 


"),s("SDTl 


”)1) 


"),s("MSXl 


"),s("SDMSXl 


")D 


"),s("L115 


"),s("SD115 


")]) 


"),s('B30 


"),s("SD30 


")]) 



Program Control 

Prolog programs operate by evaluating predicates as true or false. This process 
of eveiluating predicates is referred to as goal satisfaction. Prolog program operation 
centers around goal satisfaction by trying to find a clause where the predicate evaluates 
true. Clauses, found in the clause section of the program, can be either rules (LHS IF 
RHS.) or facts (LHS with no RHS). 



For Instance: 
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A Prolog rule: 

bkr_info(Breaker, Position, Rating) if 

bkr_posltlon(Breaker, Position) and 
bkr_ratlng(Breaker, Rating). 

A Prolog fact: 
bkr_infoL. ’error’). 

A goal Is satisfied by either finding a predicate fact clause that matches the goal or 
satisfying a rule whose LHS is the same as the predicate goal. If the current goal is to 
satisfy bkr_lnfo("SD114", Position, Rating), Prolog would first try to satisfy the rule 
shown above by satisfying each of the RHS predicates. E^ch RHS predicate is a subgoal 
to the current goal. Should Prolog not be able to satisfy any of the RHS predicates, the 
rule fails. Prolog does not give up on the goal bkr_lnfo(”SDl 14", Position, Rating) but 
rather moves to the next rule or predicate fact clause. In this case the clause 
’bkr_lnfoL. ’error’).’ is evaluated. This clause satisfies the goal predicate and returns 
the string "error” In the last argument position for the variable ’Rating’. 

At program execution the program does nothing until it receives a goal to be 
satisfied. This goal can be thought of as the question being asked. This question can be 
asked interactively, in the form of an allowed predicate, or can be pre-specified with a 
clause in the goal section of the given program. The DBMS uses a goal section clause to 
begin the program’s execution. The goal section clause indicates the predicate ’menu’ is 
to be satisfied. The DBMS contains a rule whose LHS is ’menu’. This rule Is shown in 
pseudo-code below: 

menu If get user’s ke)word command phrase input and 
accomplish command task and 
if last command isn’t ’quit’ and 
menu. 

The DBMS program then attempts to satisfy the individual predicates which 
make up the RHS of the rule. Program direction is achieved through these RHS 
predicate subgoals. One RHS predicate solicits the keyword command phrase input. 
Then another RHS predicate serving as a subgoal to the menu rule Initiates another rule 
to begin completing the user’s direction. There is a continuing sequence of RHS 
subgoals triggering new rules until whatever commamd the user gave is completed. Once 
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the original command subgoal is satisfied the program tries to satisfy the next RHS 
predicate of the menu rule. The next predicate check if the last command was to quit. 
Assuming the user doesn't want to quit, the clause recursively calls itself as a subgoal. 

In this way program execution continues until the user desires to quit. Should the last 
subgoeil have been to quit, the RHS clause falls and the menu clause fails. Likewise the 
goal clause falls and program execution stops. 

Relation Manipulation 

Decisions concerning trade ofls between speed and maximum database size play 
a large role in determining methods for database manipulation. In general, disk 
Input/output, i/o, operations reduce execution speed. Not having been able to 
Implement any sophisticated indexing method (such as a B-tree index), bringing the 
entire database into RAM, performing any necessary operations, and writing the 
resultant back to disk produces the fastest execution times. With this approach the need 
to store the original database, support individual record manipulation, and store the 
operation’s results, causes available RAM to limit the database size. 

For this DBMS, the project and join commands most relate to this problem. The 
approach taken here recognizes the importance of execution speed and works around 
current RAM constraints. Current personal computers running the Micro-Soft Disk 
Operating System. MSDOS, find themselves limited to addressing 640K of FtAM. 

The approach taken Involves bringing the entire relation into RAM for 
manipulation. RAM space be used efficiently to allow as much space as possible for 
storing the existing relation, the result of the relational operation, and to allow for the 
necessary code overhead (stack space). Of the addressable 640k RAM the MSDOS, 
program code, and program overhead takes about 240K. 400k of RAM remains for 
storage of the relation and the results of any relational operation. To make the most of 
this space during relational manipulation, records from the original relation(s) are 
removed from FIAM once they are no longer needed. Similarly, a new relation's records 
are written to disk as soon as possible. As such, less space is needed than if both the 
entire old and new files were co-resident in RAM. In addition to having space available 
within RAM to store the relation, the stack must be able to handle the overhead 
associated with the relational operation. 

Stack size is limited ty the MSDOS to 64k. The stack is used for budding 
structures, parameter storage, and in program calls, subgoal calls, and recursive calls. 
Recursion Involves a rule calling Itself. Recursion is used when the number of loops or 
operations are not known In advance. While the use of recursion is a convenient 
programming technique, it consumes stack resources until the recursion ends. In 
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keeping with the basic concept that Prolog evaluates predicates as true or false, the 
stack resources are released only If a calling predicate (goal) is either satisfied 
(evaluated true) or falls (evaluated false). The practical result is that all the space 
available to the stack, 64k, may be consumed before the relational operation Is 
completed. This results In a program error cind failure. An alternative method of 
handling situations where the number of Iterations Is not known In advance Is with the 
standard predicate ’fall’.' 'Fall' forces program backtracking to the previous subgoal. 
Additionally, when the program retreats to the previous subgoal stack resources are 
released. Using the fall predicate In place of recursion allows large relational 
operations within the 64k stack space limitation. 

In summary, current DOS limits RAM to 640k. Of this the DOS, program code, 
and stack overhead takes about 240k. The remainder, 400k, Is available for storage of 
relations and the results of relational operations. Using the standard predicate 'fall' 
allows a 64k stack to handle complex relational operations. 

Program Operation and Examples 

This section demonstrates program operation through the use of three example 
DBMS operations. These are: 

a global 'modify' of the BRANCH relation to eliminate all records without 

switching devices: 

a 'project' action on the BKRPOS relation to create a new relation, BKROPEN, 

with only open switching devices; 

a 'join' operation on the BKRPOS eind BRANCH relations to create a new 

relation, BRCHOPEN, with only those branches having open switching devices. 
Ebcamlnlng how these operations are accomplished will Include analysis of key rule 
clauses. 

The general approach to ctny of these DBMS operations is to decipher the 
keyword phrase command, input additional command directions, read the relation 
Into RAM, perform the directed operation, and write the new file out to disk. 

From the 'menu' rule clause the user’s Input of 'modify branch’ Is directed to the 
'process-modlfy' rule clause. As can be seen from figure 6. the aigument to the process 
predicate Is a string list. The list's head, "modify”, matches with this rule clause 
causing It to be pursued as a subgoal. The relation to be modified, BRANCH, Is bound to 
the variable TC. The first two RHS predicates take the tall of the command £ind convert 
it to upper case, the proper format for disk access. After erasing any existing relation 
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records and formats In RAM, the ‘whatls’ predicate, by reading the disk based format 
fQe, determines the relation format. The format Information includes: the relation 
name (BRANCH); a field length list; a field type list; and a field name list. 



Modify 

processirmodlfy" I TCI) If 
matchS(TC,Dbl,J. 
upper_lower(Db,Dbl), 
erase_db{J, 
erase_fmt(J, 

whatls(dfoimat(Db,L,T,F)), 
wrlteCType In selection criteria: \n"), 
lnput_flelds(dformat(Db,L,T,F),Fl), 
wrlteCType In new data format:\n"), 
lnput_flelds(dformat(Db,L,T,F),F2), 
wrlteC'Indlcate type modification: \n"), 
writeCglobal with no prompt -->gn\n"). 

writeC’global with prompt — >gp\n’l, 

wrlteC'delete with no prompt — >dn\n"), 

wrlteC'lndivldual changes — >Ip\n"), 

readln(C), 

concat(Db,".dba",DN), 
openread(dataflle,DN) , 
readdevlce(dataflle), 
mod_read(Db,Pf,Fl,F2,C), 
save(DN). 



Figure 6. Code listing for 'modify' Rule Clause 



The code Is now ready for specific modify instructions. The rule prompts the 
user to Indicate, field by field, what the record selection criteria Is. That Is, how should 
the DBMS determtne which records are to be modified. The rule then asks the user what 
Information should be placed In each field of the selected records. If no change is to be 
made the wildcard character, *, Is used. Four types of field modifications are supported: 
global change without any prompting; global change with Individual prompting before 
change Is effected; global delete without any prompting; and Individual record changes. 

The first example Illustrates a global ’modify’ of the BRANCH relation to 
eliminate all records without switching devices. The user-DBMS interaction to 
accomplish this operation Is shown In figure 7, with user responses in bold type. The 
user begins the Interaction with the command: ’modify branch.’ The DBMS Indicates 
the user should provide selection criteria. One at a time the DBMS prompts the user 
with a field name (along with Its type and length). As the values of node and element do 
not determine record selection the wildcard character was entered by the user. 
Records representing branch elements without switching devices have the value of 
’none' In the ’via’ field. The user's responds with 'none' when the DBMS prompts for via 



field selection criteria. The record selection responses are combined Into a list eind 
bound to the variable, FI. 

As the general procedure for the modify operation is to select records and then to 

replace field Information, the DBMS next prompts for replacement field Infonnatlon. 

This procedure Is a program shortcoming In that with the 'delete' option these responses 

are unnecessary. Any response by the user will work. The new data format responses 

are also made Into a list and then bound to F2. The type of modification to be 

completed, dn (delete with no prompt). Is bound to the variable C. 

Key Word/Phrase— > modify branch 
Type In selection Criteria: 

Field Name:node (type= s), MaxLength=8 * 

Field Nameielement (type= s), MaxLength=10 • 

Field Namervla (type=s), MaxLength=10 none 
type In new field Information: 

Field Name:node (type= s). MaxLength=8 * 

Field Name:element (type= s), MaxLength=10 * 

Field Name:vla (type=s), MaxLength=10 * 

Indicate type modification: 



global with no prompt — >gn 

global with prompt — >gp 

delete with no prompt — >dn 

individual changes — >lp 

dn 



Figure 7. Computer Screen 1 



Next the general steps of reading the relation Into RAM and making the modifications 
are both completed by the predicate 'mod_read(Db.Pf,Fl.F2,C)'. This predicate through 
Its rules acts as a subgoal the to 'process-modlfy' rule. These rules are: 



mod_read(Db,Pf,Fl,F2,C) If /*Pr is Present Record*/ 

readterm(dbasedom, dBase(Db ,Pf) ) . 
mod_match(Db,Pf,F 1 ,F2 ,C) , 
mod_read(Db,Nf.Fl ,F2 ,C) . /*Nr Is Next Record */ 

mod_read(Db._,_,_,J if 
eof(dataflle), 
closefile(dataflle). 



The first of these two rules Individually reads relation records Into RAM from the 
relation file, calls the predicate 'mod_match' as a subgoal to actually perform the 
record modification, and then recursively calls Itself to continue the process. When 
there are no longer any new relation records to be read in from the datafile, the 
'readterm' predicate will fail causing the first 'mod_read' rule to fail. Prolog will then 
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go to the second rule and try to satisfy it. This rule checks that Indeed there Is a end of 
file condition and then closes the datafile. Once satisfied, the 'mod_read' rule as a 
subgoal to its calling rule is satisfied and the program returns to the calling rule. 

The 'mod_read' rule is an example of not knowing before hand how many 
iterations will be required. When possible, the Tall’ predicate, because it doesn't create 
large stack demands, should be used to repeat the rule through backtracking. However, 
to use this technique the predicates within the rule must be non-determinlstic. That is, 
they must be capable of generating multiple solutions through backtracking. As the 
'readterm' predicate is not non-determlnlstlc, recursion must be used in lieu of the fall 
predicate. 

The 'mod_match' rules, figure 8, provide an example of how Prolog determines 
which rule to Invoke. The argument variables to mod_match are: the relation name, 
Db; the current record being considered, Pf; the selection criteria, FI; the new format 
criteria, F2; and the type of operation, C. 



mod_match(Db,Pf,Fl,F2,C), if 
not(match(F 1 ,Pf)) , 
assertz(dBase(Db,Pf)). 

mod_match(_,_,_,_,"dn"). 

mod_match(Db.Pf,_,F2."gn") if 
mod_change(Pf,F2,F4), 
assertz(dBase(Db ,F4)) . 

mod_match(Db,Pf,_,F2,"gp") if 
clearwindow, 
mod_change(Pf.F2,F4), 

writeC'Change top record to bottom? (y/n)\n "), 
wrlte_data(Pf) ,wrlte_data(F4) , 
readdevlce(keyboard) ,readln(C) .readdevlce(datafile) . 
mod_act(Db.C,Pf.F4). 

mod_match(Db.Pf.Fl.F2."ip") if 
clearwindow, 
mod_change(Pf,F2 ,F4) , 

writeC'Change top record to bottom? (y/n)\n "), 
wrlte_data(Pf),write_data(F4), 

readdevice(keyboard) .readln(C) .readdevice(datafile) , 
mod_act(Db.C,(l.F4). 

mod_match(_, 

Figure 8. Listing for 'mod.match' Rule Clause 



Prolog begins with the first rule emd checks if it can be satisfied. As the arguments to 
the first rule are all variables, the passed variables bind to the LHS variables and the 
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rule win be satisfied if the F?HS predicates are satisfied. The 'match' predicate checks 
whether the record being considered matches the selection criteria. Because of the 'not' 
modifying this predicate, it will only succeed when they do not match. This condition 
Indicates that the record fails to meet the selection criteria and It Is asserted into RAM 
unmodified. If this version of the rule succeeds. Is satisfied, control returns to 
'mod_read' for the next relation record. Should the record and the selection criteria 
match, the 'not' modifier would cause the predicate and likewise this version of the 
'mod_match' rule to fall. 

When one version of a predicate's rule falls, Prolog moves to the next listed rule. 
In the second version of these rules. Instead of normal variables the first four 
arguments are the Emonymous variable '_' which can be bound (and satisfied) by 
cm)dhing. This Is used when the values of these arguments do not matter In the logic of 
the rule. The last argument of this rule Instead of having a variable has the string "dn" 
shown. To bind to this cirgument the calling predicate's argument must be the same, l.e. 
"dn". As the first four arguments contain the anonymous variable, to satisfy the LHS of 
this rule the calling predicate need only match the last argument with the string "dn". 
Note that this rule has no RHS. Simply matching the last argument to "dn" satisfies the 
rule. 

The general form of the LHS of the 'mod_match' rules Is to pass any necessary 
Information through the first four arguments and the operation to be performed 
through the last argument. The RHS of the rules performs the necessary operation and 
asserts the new record Into RAM. In the case of the 'delete' operation, the necessary 
operation Is to delete the record, l.e. not assert It Into RAM. This rule therefore needs no 
RHS. 

After all the records have been processed the revised relation resides In RAM. 
Control returns to the 'process-modify' rule where the last RHS predicate writes the 
relation to disk. The example relation, BRANCH, was a 28,000 character file with 434 
records. The DBMS took 5 seconds to read and examine each BRANCH record. Identify 
193 records containing the value "none" In the via field, assert the other 335 records 
Into RAM, and save the modified relation to disk. 

The keyword phrase 'project bkrpos bkropen' activates the 'process-project' rule 
clause, figure 9. The desired effect of this operation is to generate a new relation, 
BKROPEN, consisting of all the BKRPOS records which have the value of "open" In the 
position field. Figure 1 1 shows the user-DBMS Interaction required to direct this 
operation. Note that the computer prompts the user for 'JOIN' field Information. This 
message Is a result of the project command sharing code with the join commcmd. 



37 



Project 

processirprojecf'ITCJ) if 

cleanvlndow,cursor(0,0) . 

matchS(TC,Db Il.TC 1) ,matchS(TC 1 .DbNewl, J . 

upper_lower(DBNew,DbNewl), 

upper_lower(Db 1 ,Db 11), 

wrt_fld_names (Db 1 ) . 

M= 1 ,J oln_flds(Db 1 ,M ,TN 1 .TV 1 ) . 
echo(Dbl.TNl.TVl), 
posiUonstDb 1 ,TN 1 .TPl .TTl .TLl), 

DbClauses(Db 1 . TP 1 .TV 1) . 
nextstep("n".DbNew,TL 1 .TTl ,TN 1 ) , 
mkNew(Dbl."".DbNew.J. 

writeC'Project complete. Hit return to continue."). 
readln(_). 

Figure 9. Listing for 'project' Rule Clause 



VaUd BKRPOS fields: 
via position 

Indicate JOIN field #1: via 
Indicate selection Value (*=wlldcard): • 
Indicate JOIN field #2; position 
Indicate selection Value (*=wlldcard): open 
Indicate JOIN field #3: 

Selected criteria from dbase BKRPOS: 
via * 

position open 



Project complete. Hit return to continue. 



Figure 10. Computer Screen 2 



Similar to the 'process-modlly' operation, the DBMS prompts the user for responses. In 
this case the DBMS shows the available (valid) fields for the project operation. The 
project command allows the user to create a new relation with any or all off the 
attribute fields of the original relation. The order in which the user gives the field 
attribute names to the DBMS will be the order the attributes will appear in the new 
relation. The user also may Indicate a selection criteria for each field to be Included in 
the new relation. Figure 10 shows that no selection criteria should be used with the Via' 
field values but that only records with 'position' field values of 'open' will be included in 
the new relation. The DBMS continues to ask for field information until the user 
responds with only the return key. After the user completes the selection process, the 
DBMS echo prints the selected fields and the values for each field. 

The first new RHS predicate in this rule is the 'positions' predicate. This 
predicate takes the list of selected fields for the new relation and extracts the necessary 
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format Information: field neunes; field lengths; and field types from the original 
relation format file. The rules associated with the predicate 'DbClauses' reads into 
RAM the entire orlgincd relation, finds those records which meet the selection criteria 
(via field value of "open"), and asserts Into RAM the new relation’s records. 

The relation records which meet the selection criteria need to be 'conditioned' 
prior to becoming records for the new relation. In the case where not all fields of the 
original relation sire used in the new relation, this conditioning includes extracting the 
appropriate field Information and discarding the undeslred field’s data. Next the data 
Is reordered as indicated by the ordering the user gave In the criteria selection process. 
Lastly, before asserting the data as a new record, the data Is verified as non-redundant 
(non-duplicate). 

The predicate 'nextstep' creates a format file for the new relation and an empty 
datafile for the relation. The predicate 'mknew', by writing the new relation to the 
datafile, completes the 'process-project' rule. The 'mknew' rules Illustrate backtracking 
by use of the fall predicate. The pertinent 'mknew' rules are: 

mknew(Dbl,'"',DbNew,J If 

concat(DbNew,".dba",DName), 
openappend(datafile,DName) , 
writedevlce(dataflle) , 
dBase(Dbl,Fdl), 

write terms(dBase(DbNew,Fdl)), 

retract(dBase(Db 1 ,Fd 1 )) , 

fall. 

mknew(Dbl,"",DbNew,J If 
closefile(dataflle) , 
writedevice(screen) . 

The program goes through the first rule until It hits the 'fail'. The ’fall’ predicate always 
falls and causes the program to backtrack to the first non-determtnlstlc predicate 
seeking an alternative solution from that, the non-determlnistlc, predicate. In this 
case, the only non-determinlstic predicate Is the 'dBase' predicate, the djmamlc 
database predicate. It finds the next relation record. After the dBase predicate succeeds, 
having found a new relation record, the predicates following It are repeated. The 
process of finding a relation record and writing it to the datafile Is repeated until the 
dBase predicate falls, l.e. there are no more relation records. At this point this mknew 
rule falls and Prolog moves to the next mknew rule. As can be seen, the next rule closes 
the datafile and returns output to the screen. 

The source relation, BKRPOS, was a 1 1,500 character file with 250 records. The 
DBMS took 33 seconds to read In the records, delete 181 records not containing the 
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value "open" In the via field, create 69 new records in RAM, create the new format file 
and empty datafile, and write the records to the BKROPEN datafile. 

The final example Illustrates the Join' operation. The Join operation takes 
advantage of the DBMS using the relational model. By using a relational model. 
Individual relations can easily be joined to form more complex relations through 
common attributes. The join operation takes two relations and forms a third. The two 
original relations must have one or more common attributes. Any number of the 
common attributes can be used in specifying the join operation. Consider the command 
'join branch bkrpos brchopen'. The relations BRANCH and BKRPOS act as source 
relations. The newly created relation will be BRCHOPEN. This command takes the 
program to the 'process-join' rule, figure 1 1. Figure 12 shows the additional specific 
command direction required to accomplish this operation. 

As with the 'process-project' rule, the user is prompted with the first relation's 
attributes and a request for the first 'JOIN' field. Join fields must be common between 
the two relations. The selection value specified will determine which records are 
joined. In this example, records with common 'via' field values will be joined. The user 
hits the return key when no further 'join' fields are needed. 



Join 

process(|"joln"lTC)) if 
clearwlndow, cursor(0,0), 

matchS(TC.Dbll,TCl),matchS(TCl,Db21,TC2),matchS(TC2,DbNewl,J, 

upper_lower(DBNew,DbNewl), 

upper_lower(Db 1 ,Db 1 1) , 

upper_lower(Db2,Db21), 

wrt_nd_names(Db 1) . 

M= 1 ,join_flds(Db 1 ,M, JN 1 . JV 1) ,nu_fids(NuKey, JN 1) ,nl, 

N=l,othr_fids(Dbl,N,ONl,OVl), 

j oinlistSf JN 1 ,ON 1 ,TN 1 ) , 

joinlistD(JVl,OVl,TVl), 

echo(Dbl,TNl,TVl), 

wrt_fld_names(Db2) , 

L= 1 ,othr_fids(Db2,L,ON2,OV2), 

joinlistSfJN 1 ,ON2,TN2) , j oinlistDfJV 1 ,OV2 ,TV2) , 

echo(Db2,TN2,TV2), 

joinllstSfTN 1 ,ON2,TNnew) , 

joinllstDfTVl ,OV2 ,TVnew) , 

echo(DbNew,TNnew,TVnew) , 

positionsfDb 1 ,TN 1 ,TP 1 ,TT 1 ,TL 1 ) , 

positions(Db2 ,TN2 ,TP2 ,TT2 ,TL2) , 

DbClauses(Dbl,TPl,TVl),write("lst clauses complete") ,nl, 
DbClauses(Db2,TP2,TV2),write("2nd clauses complete"),nl, 
mkfmt(DbNew,NuKey,TN 1 .TTl ,TL1 ,TN2,TT2,TL2), 
mkNewfDb 1 ,Db2,DbNew,NuKey) , 
wrlteC'Joln complete. Hit return to continue."), 
readlnfj. 

Figure 11. Listing for 'join' Rule Clause 
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In addition to the Information concerning the Join fleld(s), the DBMS needs to 

know what 'other' fields from the first source relation will contribute to the new 

relation. Also for the other fields Indicated, by specifying specific field values only 

those records qualifying (meeting the selection criteria) will move to the new relation. 

From the computer screen, the field 'element' with the wildcard selection value will 

cause the 'element' field to be Included hi the new relation without any selection process 

on the value of the field. The remaining field of the BRANCH relation, node. Isn't used. 

For the second source relation, BKRPOS, no Join field Information Is required. 

That Is because the join Information will be the same for both source relations. The 

DBMS proceeds directly to soliciting information 

Valid BRANCH fields: 

node element via 

Indicate JOIN field #1: via 

Indicate selection Value (*=wlldcard): • 

Indicate JOIN field #2: 

Indicate other field # 1 : element 
Indicate selection Value {*=wUdcard): * 

Indicate other field #2: 

Selected criteria from dbase BRANCH: 
via * 

element * 

VaUd BKRPOS fields: 
via position 

Indicate other field #1: position 
Indicate selection Value (*=wlldcard): open 
Indicate other field #2: 

Selected criteria from dbase BKRPOS: 
via * 

position open 

Selected criteria from dbase BRCHOPEN: 
via * 

element • 
position open 



Join complete. Hit return to continue. 

Figure 12. Computer Screen 3 



concerning the other fields to be included in the new relation. From the computer 
screen dialog, the field 'position' is selected with a field value of "open". Again like the 
'project' command, the selected criteria for the new relation, BRCHOPEN, Is echo 
printed. 

Table 9 shows selected relation records from the two source relations and one 
resultant record. The first record shows the field names. Shown in bold print is the via 
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field value, sdmhS, which matches between the shown BRANCH and BKRPOS records. 
Since the via attribute has been specified as the Join field these two records are 
candidates to be Joined together. Since for the ’position’ field from the BKRPOS relation 
was specified as "open" the candidate BKRPOS record must also have the value of "open" 
In its ’position’ field. It does. The last record In the table is the resultant record. The 
first element of the data list is the via field value of "sdmhS". The second member of the 
list, "bmhS", is the value of the ’element’ field of the BRANCH relation record. The last 
member of the new record, "open", is taken from the position field of the BKRPOS 
record. 



dbase(’BRANCH".Inode field, 
dbase(’’BRANCH’’.[s(’’n2.39 
dbase(’’BRANCH’’.(s(’’n2.39 
dbase(’’BRANCH’’.Is(’’n2.39 



Selected Relation Records 

element field, via field 
"),s(’bmh8 ").s(’’sdinh8 

’lsfbl014 ’’),s(’’sd 1014c 

").sfbl015 ").s(’’sdl015c 



I) 

”) 1 ) 

”))) 

")]) 



dbase("BKRPOS’’.[vla field. position field)) 

dbase(’BKRPOS’’.|s(’’sd313 ’’).s(’’closed’’)l) 

dbase(’BKRPOS’’.|s(’’sdt3 1 ’’) .s(’’closed") 1) 

dbase(’BKRPOS’’.ls(’’sdmh8b ").s(’’open ’’))) 

dbase(’’BRCHOPEN".lvla field. element field, position field]) 

dbase(’BRCHOPEN’’.Is(’’sdmh8b ").s(’bmh8 ").s(’’open”) 

The RHS predicates of the of the ’process-join’ rule are similar to the ’process- 

project’ rule. The DbClauses predicate is used twice. That allows inserting Into RAM the 

candidate records from each of the source relations. The ’mkNew’ predicate assumes 

additional responsibilities within the ’process-join’ rule. The ’mkNew’ rule matches 

appropriate candidate records and combines them to form the new record. After 

forming the new record, it verifies that it isn’t a duplicate record, asserts the record Into 

RAM. writes the record to the datafile, and falls In order to repeat the process. 

In this example operation, the relation BRANCH was a 28,000 character fUe 

with 434 records, the BKRPOS relation was a 1 1,500 character file with 250 records. 

The resultant relation, BRCHOPEN, has 4500 chciracters and 69 records. This Join 

example took 5.75 minutes to complete. This result is definitely not fast. Each of the 

previous examples where originally run on an IBM AT with a hard disk storing the 

datafiles. To see how much of the execution time was attributable to disk l/o the project 

and Join examples were repeated with the datafiles stored on a RAM disk. The observed 

times using a RAM disk were only 1-5 seconds faster than the times observed when the 

datafiles were stored on a hard disk. The time Improvement is so small because hard 

disks are fast and the DBMS rules limit disk l/o in the project command to two, one 

read for the source relation and one write to save the new relation, and In the Join 
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command to three, two reads for the two source relations and one write to save the new 
relation. 



DBMS Concluding Remarks 

This chapter provided an overview of Implementing a relational model DBMS 
in Prolog. This included a brief discussion of DBMS functions, examples of relational 
operations, and design and programming consideration Influenced by the Prolog on an 
IBM AT environment. From the previous discussions one can see the power of a DBMS 
as a data management tool. The use of a relational model stated In FNF further 
enhances a DBMS's capabilities. These features motivate Its use as a supplement to an 
ES. 

The time required to perform the relational operations Is judged as marginal at 
best. Since the execution times did not improve when using a RAM disk to store the 
datafUes. the execution time is dependent on the DBMS rule coding. This result reflects 
the lack of a indexing scheme to rapidly retrieve and match database records. 



Chapter m: The Eacpert System 



Expert System Introduction 

This chapter demonstrates the ES and validates its use as a distribution system 
engineering aid. The ES’s goal and basis are briefly reviewed. Preliminary comments 
consist of a brief characterization of the ^stem model and a description of the three 
classes of problems considered by the ES. This project proposes that the ES and DBMS 
be jointly used as an off-line engineering aid. For each class of problems, 
demonstration and validation consists of three principle steps. The first step describes 
the nature of the given class of problems. Second, examples demonstrate how to present 
the problems to the ES and how the ES responds. The last step addresses the 
methodology for solving that class of problems. 

BS Goal Statement 

The goal of the ES and DBMS package Is to provide users with an off-Une tool for 
analyzing problems concerning system connectivity. This goal fulfills the dominant 
need of those managing the Bangor Submarine Base distribution system which Is being 
able to analyze ways of configuring the system to meiintaln service to loads. 

Connectivity 

Connectivity refers to the paths used for transferring power from sources to 
loads. From the DBMS, three relations model the distribution system. The first, the 
BRANCH relation, represents the system topology as a set of connected branch 
elements. Each relation entry consists of a branch node/element pair and a switching 
device. The node establishes the connection points between branches. The switching 
device controls power flow through the element. The second relation, BKRPOS, stores 
switch position information. The switching devices may be either open or closed. The 
third relation, BDESC, categorizes elements as either sources, loads, or lines. In the 
natural sense, sources provide power, loads consume power, and lines transmit power. 
The description 'Une' is used for distribution lines, transformers, any other 
miscellaneous components which do not provide or use power. The ES, using the 
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information from these relations, examines cormectlvity, i.e. how power is or could be 
transferred from sources to loads. 

Three general classes of connectivity problems are considered. First, Initial 
system analysis determines the condition of the distribution system based on the 
distribution system database Information. The analysis includes which loads are 
energized, the branch elements which make up the power flow paths for each loads, and 
a determination of all energized line elements. The second class of problems concern 
how the distribution system condition changes as a result of single elements being 
taken out of service. The elements considered are switching devices as well as the three 
branch element types— sources, lines, and loads. For loads and lines, tciklng the 
element out of service assumes a short circuit fault requiring the opening of switching 
devices to isolate the fault. For switching devices, removing from service means either 
a user opening a switch or the switch falls and opens. For these situations the ES 
determines which loads become de-energlzed, the closest switching devices to isolate 
the fault, and what lines become de-energized as a result of isolating the fault For fault 
isolation, the ES does not consider If switching devices operate automatically or 
manualfy. The ES determines which switches must be opened to minimize the affected 
fault area. Third, the ES determines alternative paths for restoring de-energlzed loads. 
Finding a restoration path requires determining routes over currently unenerglzed 
lines, but not out-of-servlce lines, to currently energized lines. The ES does not provide 
a sequence of switch operations to realize the restoration paths but does Indicate what 
switching devices need to be closed. 

Initial System Analysis 

Problem Nature. Initial system analysis determines the path(s) energizing each 
load and Identifies the energized distribution lines. To accomplish this, the ES must 
imk with the DBMS to receive the information in the distribution system database. 

The database consists of three DBMS relations— BRANCH, BDESC, and BKRPOS. The 
ES uses a single relation, BINFO. BINFO, which stands for "branch information’ has the 
following form: 

(node, branch element- >type, switching device, position). 

Using the BINFO relation, the 'type' attribute identifies sub-stations and generators as 
sources. Sources provide power to loads through the distribution lines. To energize a 
load a continuous path, a loadpath, must exist between a source and the load. To 
determine how a load Is energized the ES starts at the load and Investigates all possible 
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paths leading from It. In this way the Initial analysis determines every path, branch by 
branch, which leads from a load to a source. Normally only one such path exists. As 
there may be energized branches which are not part of any loadpath determining 
loadpaths to the loads Is not sufficient to determine all the energized branches. 

To determine energized distribution fines the ES starts at each source and works 
outward. Aity fine connected to the source Itself or an energized fine Is energized. 
Reaching these conclusions Involves applying the ES’s rules to the Information 
contained in the distribution system database. 

Alternative Initial ^stem configurations can also be analyzed. WhUe 
remaining In the ES, the user can directly enter the DBMS program to change the 
position of the switching devices to reflect another system configuration. Upon 
completion of the DBMS operations, ES program execution resumes. The user can then 
perform an Initial system analysis using the modified distribution database. In 
addition to analyzing the system with different switching device configurations, 
different fine arreingements, I.e, topologies, can be Investigated. To determine the effect 
of removing fines, records are deleted from the DBMS's BRANCH relation. Without 
entries In the BRANCH relation the fines do not affect the system’s topology. Similarly, 
to determine the effects of new fines, records are added In the BRANCH, BDESC, and 
BKRPOS relations. Entries must be made In each relation to fully describe the nature of 
the new fines. Using the DBMS to modify the database relations allows the ES to 
analyze the current system topology with alternative switching positions or system 
configurations based on modified topologies. 

User/ES Interaction. The ES, like the DBMS, uses natural language querying. 
The command 'paths' Invokes the relation preparation program. The relation 
prepziratlon program loads Into RAM, prepares the relation BINFO, and then the ES 
resumes. Upon resumption the ES reads Into working memory the relation BINFO, and 
begins determining the loadpaths. The ES responds to the user by Indicating which 
load Is being considered. Each loadpath found for that load Is displayed. When the 
determines there are no additional loadpaths for the load it finds another load to 
analyze. This loop continues until all loads have been completed. These loadpaths are 
asserted as dynamic database facts into working memory. 

The command 'energized' starts the ES finding energized fines. Any line 
connected directly to or through other energized fines to a source is an energized fine. 

As the ES determines a fine Is energized it displays this conclusion to the user and 
asserts this new fact Into working memory. 
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Methodology. The methodology for finding all loadpaths Involves three steps. 
First, Invoking the relation preparation program and reading Into working memory 
the resulting BINFO database. Second, finding a load not already evaluated. Third, 
finding that load’s loadpath(s). TTie second and third steps are repeated untU no further 
loads require Investigation. 

The ES begins by first calling a relation preparation program. This preparation 
program links to the ES the distribution system database information stored In the 
DBMS as three relations. They are; 

BRANCH: (node, branch element- >vla), 

BDESC: (branch element->type,rating), 

BKRPOS: (vla->posltion). 

The relation preparation program Joins the three relations into a single relation, 
BINFO, of the form: 

(node, branch element->type, switching device, position). 

This preparation progreim is equivalent to the DBMS performing three relational 
operations—two joins and a project. The first DBMS Join operation Joins the relations 
BRANCH and BDESC using the common attribute Tjranch element.’ As the does not 
need to know about branch element ratings, this attribute Is not included In the new 
relation, TEMPI. TEMPI has the following form: 

TEMPI; (branch element, node->vla, type). 

The second Join operation Joins the BKRPOS and 'TEMPI relations using the common 
attribute ’via.’ 'The form of resulting relation, ’TEMP2, is: 

TEMP2; (via, position, node, branch element, t)T>e). 

While the required information is In a single relation, the ordering of the attributes Is 
not what the requires. 'The DBMS would next have to perform a project to reorder 
the attributes as required by BINFO. 'The Via’ attribute of TEMP2 and the ’switching 
device’ attribute are the same attribute with different labels. 

In addition to forming a correctly ordered single relation, the DBMS and ES 
handle the information In a different format. To Illustrate, one record of TEMP2 is: 
dbase("TEMP2",Is(”sdmh8 "),s("open "),s("n2.33 "),s("bmh8 ” ),s(’load ”)]). 

One record of BINFO, In the E^, Is; 

blnfo("n2.33","bhm8”,"load","sdmh8","open"). 
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The difference arises from the need of the DBMS to use a generalized data storage 
format whereas the ES, as a specific application, can use a specific predicate format. 
The link between the DBMS and ES must also perform this format change. 

To perform these operations several alternatives existed. The DBMS could be 
used to perform the two 'joins’ and a 'project* to create a BINFO relation In Its 
generalized format. A special format conversion routine could then perform the 
required conversion. Similarly, the appropriate routines from the DBMS and the 
conversion routine could be incorporated In the ES Itself. This alternative would save 
having to Invoke the DBMS and enter the commands manually. The acceptability of 
the program size Increase would depend on the ability of the remaining RAM to handle 
the relational operations. A third alternative approach was to perform the format 
conversion and the relation combinations with routines written for these specific join 
operations. These routines could also exist as a stand alone program or as part of the 
ES. 

Two of these approaches were examined. The Indicated relational operations 
were performed by the DBMS and a stand alone relation preparation program. The 
results of the DBMS operations follow: 

join branch bdesc tempi : 9.75 minutes; 

join bkrpos tempi temp2: 1 1.2 minutes; 

project temp2 binfo: 3.0 minutes; 

total: 23.95 minutes. 

These same operations using RAM disk Instead of a hard disk were 13 seconds faster. 
Due to the excessive time required for these three operations, the format conversion 
routine was not developed. The stand alone BINFO relation preparation program took 
1.75 minutes to read the three relations, perform the format conversions, form the new 
relation, and store the new relation on a hard disk. As neither of these approaches used 
sophisticated data look-up methods, the time Improvement Is attributed to using 
routines for specific relation operations rather than generalized operation routines. 

This project Implemented the DBMS-ES Information link as a stand alone 
relation preparation program. The preparation routines were not Included In the ES 
program code because one, their inclusion would Increase ES code size without offering 
a significant speed Improvement and two, these operations were felt to be more DBMS 
related than related. 

Once the relation preparation program prepares the BINFO database, the ES 
places It In working memory as a dynamic database. The ES next Identifies which 
system elements are loads and then determines their loadpaths. The goal 
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blnfo(Node,Branch,"load",Switch,Posltlon) finds a branch which Is a load. Once a load 
has been Identified, the ES traces all connected paths from the load. Any path which 
ends at a source is a loadpath. The loadpath Is then asserted into working memory. 
Paths which terminate at open switching devices or other loads cire not loadpaths. 
These loadpaths are developed using two rules. Shown tn pseudo-code: 



rule 1: 

Make the current branch the end of the loadpath list If 
the branch Is a source. 

rule 2: 

Add the current branch to the loadpath list If 

Its switching device Is closed and (1) 

the node/branch pair hasn't been considered and (2) 

there Is another branch, branch2, connected to branch (3) 
whose switching device Is closed and (4) 

node/branch2 hasn’t already been considered and (5) 

It leads to a source. (6) 



The first rule recognizes that a source branch completes a loadpath. The second rule 
builds the list of branches leading to the source. Line (1) recognizes that to be part of the 
loadpath the branch’s switching device must be closed. Line (2) ensures that only paths 
not previously checked cU"e pursued. The last condition necessaiy to add this branch to 
the loadpath list Is that It be connected to another branch which leads to a source. Lines 
(3) through line (6) checks this. Line (6) Is a recursive call back to these two rules. 

Finding the loadpath for B5730 illustrates the action of these two rules. The 
part of the system dealing with this search Is shown in figure 13. The ES, using these 
two rules, finds the loadpath(s) for B5730. Rule 1 checks If B5730 Is a source. The 
database clause blnfo("nl.l0",”b5730","load","sd5730","closed") identifies this branch 
as a load and so the rule falls. The second rule also examines this predicate clause. 

Since the ’position’ attribute Indicates the switch to B5730 Is closed the ES should 
follow this path. The closed switching device causes first line to evaluate true. Because 
this branch has not been previously considered the second line of the right hand side 
(rhs) evaluates true. Line (3) looks for a branch which Is connected to this branch. To be 
connected to the current branch the new branch must share the node nl . 10. From the 
figure that would be branch LI 14f. The database clause 

blnfo("nl.lO","L114f’,”line","none","closed") tells the ES that this branch element’s 
switching device Is closed. Line (5) Is satisfied as this new branch has not been 
previously considered. 
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To check If node/branch 'nl. 10/Ll 14f leads to a source the rule recursively 
calls Itself with the current branch becoming ’Ll 14f . Rule 1 again falls. Rule 2 Is now 
checking bramch LI 14f. This time line (1) finds 

blnfo("nl.8","L114f',"llne”,"sdL114f',"closed") which Is the other node/branch 
combination sharing the branch LI 14f. Rule 2 checks that this node/branch pair has 
not been considered previously. With this combination of rules finding node/branch 
pcilrs "With closed switching devices the ES can move from node to node and from 
branch to branch. Line (3) now looks for a branch which Is connected to node nl.8. 
From the drawing. LI 14y, LI 14x, and LI 14g all connect to this node. If the ES selects 
LI 14g It will continue the previous process unto It runs Into a dead end at B5065. The 
ES backtracks to nl .8 and then may select LI 14x. The previous process again continues 
until reaching blnfo("nl.l2", "Lspld","Une"."sdlm","open"). This branch falls because 
the switching device Is open. The ES again backtracks to nl.8. This time the only 
remaining untried path Is LI 14y. Depending on how the 'binfo' predicate clauses are 
arranged In working memory the ES may follow other faulty paths or go directly to 
subl through sdLl 14. Once subl Is the branch being considered, 

blnfo("ns3","subl",’'source","none",”closed") will allow rule 1 to succeed. The list [b5730, 
LI 14f, LI 14y, LI 14z, subl] Is saved In working memory as loadpath("b5730", [LI 14f, 

LI 14y, LI 14z, sub Ij). The first argument of the loadpath predicate Is the load's name. 
The loadpath list Is the second argument to the predicate. After determining one 
loadpath the ES backtracks through each node Investigating all possible paths from 
that node. For this example, each path eventually leads to an open switch or another 
load. Therefore B5730 has only a single loadpath. 

After all possible routes have been checked, the ES selects another load and 
reapplies these two rules. This continues until all loads have been worked. Having 
completed the 'paths’ command the ES returns to the user prompt to await the next 
direction. 
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Figure 13. System Extract for B5730 Loadpath 
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The second part of initial system analj^is consists of determining energized 
distribution lines. Rules similar to the loadpath rules find the energized lines. 



rule 3 /• considers branches which are sources*/ 
node /branch is evaluated if 

branch Is a source and (1) 

node/branch not previously considered and (2) 

place In working memory as energl 2 sed and (3) 

find another branch, branch2, to consider which (4) 

Is coimected to this node with a closed switch and (5) 

has not previously been considered and (6) 

evaluate the node/branch2. (7) 



rule 4 /‘considers lines with closed breakers at each end*/ 
node/branch Is evaluated If 



node/branch not previously considered and (8) 

place In working memory as an energized line and (9) 

find other node, node2, for branch and (10) 

switch for node2 /branch Is closed and (11) 

find another line branch, branch2, to consider which (12) 

Is coimected to this node2 with a closed switch and (13) 

has not previously been considered and (14) 

evziluate the node2/branch2. (15) 



The search for energized branches Involves transverslng through closed switches the 
tree made up of Intercormected source and line branches. Any such tree begins at a 
source branch and expands out over line branches until an open switch or a load are 
encountered. The 'energized' command begins a tree by finding a branch which is a 
source. For example, the following predicate clauses represent the branch elements 
which make up subl: 

blnfoC'nsl", "subl". "source", "none","closed"): 
blnfo("ns2", "subl", "source", "none", "closed"): 
blnfo("ns3". "subl". "source", "none", "closed"): 
blnfo("ns4", "subl", "source", "none", "closed"): 
binfo("ns5", "subl"," source", "none". "closed"). 

Rule 3 handles these type clauses. Any one of these clauses can act as the starting point 
for the ES. Lines 4-6 begin the tree search by finding a prevlousty untraversed 
coimectlng brcinch Avith a closed switch. Rule 4 line (8) checks that the new 
node/branch pair have not been previously checked. This rule always evaluates true 
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when expanding the tree. It is placed as the first rule to promote fast backtracking when 
the rule falls. Line (9) asserts into working memory that the new branch Is energized. 
Line (10) finds the other node associated with the current branch. Line (11) checks if the 
switch associated with this node Is closed. If It is, the rule looks for another line branch 
with a closed switch to expand the tree onto. If the switch associated with the second 
node is open the rule falls. This rule causes the tree to expand along a path until It 
reaches either a load, a source, or an open switch. The rule then falls and backtracks to 
an unexplored line branch. When the entire tree Is explored rule 2 backtracks to rule 1 
and another source branch Is found. The new source branch begins a new tree. This 
process continues until all source branches have been tested. 

At this point the ES has completed the initial system analysis. Working 
memory contains the original BINFO system database, the derived loadpath clauses, 
and the energized line clauses. The ES is now ready to respond to the effects of opening 
circuit breakers, single element faults, and restoring de-energlzed loads. Additionally, 
the contents of working memory can be saved to disk for later use. The 'save' command 
saves all database clauses to disk. These can later be read directly into working 
memory by the 'consult' command. When Prolog saves dynamic database clauses to 
disk, all clauses of every type are saved In one file. While this project did not do so, a 
relation preparation program could be developed to convert the individual clauses into 
separate relations of the general format required by the DBMS. 

These two ES operations, finding the loadpaths and the energized distribution 
fines, are the most computationally intensive. They involve first reading from disk the 
44 1 BINFO relation records into working memory. Eivery possible path from each load 
is investigated to see if It leads to a source. From each source every branch is examined 
to determine If It is an energized fine. The process to determine all loadpaths takes 40 
seconds to complete. The process of determining energized branches 58 seconds. 

Several versions of the rules for determining energized paths were examined. While 
each version of the rule produced the same results their performance varied by 230%. 
The time Improvements resulted from using the fall command instead of recursion 
when possible and by reordering RHS subgoals. The time differences Illustrate that 
optimized performance results from efficient tree searches and efficient backtracking. 
The performance and accuracy of the ES In this task cajinot be duplicated by even the 
most proficient user of the distribution system. 



Single Element Failure 
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Problem Nature. The ES handles the distribution system's two most common 
single element failures. These are a switching device falling open and a branch element 
shorting. These are the type situations for which the off-line users need the ES to 
analyze as 'what-lf problems. 

The switching device failure results in the switching device being left open 
without the ability to reclose It. The ES must determine the effects of Interrupting 
power flow through the branch served by that switch. Interrupting power through a 
branch may cause loss of power to loads and de-energlze distribution lines. The ES 
must also identify the switch as being out of commission (ooc). By noting that the 
switch is ooc the knows the switch Is no longer available for use. The ES also accepts 
an 'open switch’ command. The only difference between opening a switch and a switch 
failing open Is that the former Isn't labeled as being ooc. 

The ES also considers the results of a branch element faulting as a short. Any 
branch element— a source, load, or line— can be shorted. When a short occurs the ES 
must determine which circuit breakers open, what lines are de-energlzed, and which 
loads are de-energlzed. In this case the opened circuit breakers are classified as 'lost.' 
Their use as switching devices are lost because they must remain open to isolate the 
fault . 

User/ES Interaction. Before beginning a 'what-lf simulation, the ES must 
complete an initial system analysis or have loaded Into memory, using the consult 
command, the results of a previous analysis. 

The first of the two types of single element failures Is the opening of a switching 
device. The user gives the command 'open switchname' to Indicate simply opening the 
switch. The command 'ooc switchname' Indicates the breaker opens and Is out of 
commission. When opening a switch or breaker the ES first checks the device's current 
position. If It Is already open the user Is so notified. If it is closed, its position Is 
changed to open and the user Is notified what branch It controlled power flow through. 
Once the ES has determined which branch had power flow Interrupted it can determine 
the results of the Interruption. As the E^ identifies de-energized loads the user Is 
notified. Their status Is also changed to de-energlzed loads In working memory. 
Distribution lines which become de-energized are removed from working memory. 

The other type failure Is a branch element shorting. When dealing with a 
shorted branch element the E)S must first find the area necessary to Isolate the short. 
The ES determines the boundaries of this area by checking all paths leading from the 
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fault. For each path the ES finds the closest switching device which can Isolate the fault 
from the remainder of the system. The ES notifies the user which switches need to be 
opened. The knows that. In addition to Isolating the fault, opening a switch 
Interrupts power through that switch's branch. By knowing which branches have had 
power Interrupted the ES can determine which loads are lost in Isolating the fault. This 
Information Is all reported to the user. The final step of fault analysis Is redetermining 
the energized lines using the method previously discussed 

At this point working memory contains the original system information In the 
relation predicate clauses, the derived loadpath clauses, and the energized line clauses, 
what switch devices are ooc, and what switches have been opened to Isolate faults and 
therefore cannot be reclosed, and which loads have been lost due to the single element 
fault. Using the 'save testname' command transfers a copy of the working memory’s 
Information to disk. This command creates a new datafile on the hard disk. As with 
Initial system conditions saved to disk, this system condition can later be recalled with 
the command 'consult testname.’ 

The user may also study the effects of multiple faults. Multiple faults and switch 
openings can be simulated by a sequence of single element faults and switch openings. 

Methodology. The methodology for handling the effects of opening a switch and 
a switch faulting open are similar. The only difference in these two situations is that 
the faulted switch needs to be Identified In working memory as ooc. This identification 
Is accomplished by asserting the predicate ooc(swltch_name) Into working memory. 
The actual opening of a switch produces straight forward results. If it was already open 
the ES merely notifies the user and returns to the prompt mode. If not, the ES chctnges 
Its position in working memory by retracting the binfo clause with a ’closed’ position 
value and asserting a binfo clause with an ’open’ position value. Next the ES determines 
what the switch controlled power through or to. Each switching device directly controls 
power flow in a single system element. As an example of opening a load breaker 
consider the system portion serving Quarters Group 7 shown In figure 14. 
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Figure 14. System Portion Serving Quarters Group 7 
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The user gives the command 'ooc sdq7’. From blnfo("n2.20", "qtrs7", load. "sdq7", 
"closed") the ES knows that switch sdq7 controls power to qtrs7 which is a load. For 
loads the deals only with loadpaths for that specific load. For this load these would 
be In one of two forms: loadpath("qtrs7", [L216f, ...]) or loadpath("qtrs7", IL215d. ...)). 
This is because all loadpaths for qtrs7 begin with either line L2l6f or line L2l5d. From 
the figure, one sees that opening sdq7 interrupts power from L216f. Therefore the ES 
retracts the loadpaths of the form loadpath("qtrs7", [L216f, ...)). The ES next needs to 
determine if the load, qtrs7, was de-energized. If any loadpaths of the form 
loadpath(”qtrs7", (L215d, ...)) exist the load remains energized. Otherwise the load was 
de-energIzed. If the load were de-energIzed, the asserts the Inferred fact that the load 
named qtrs7 was de-energized, deen("qtrs7"). Into working memory . 

As an example of Interrupting power flow through a distribution line consider 
the command 'open sdl 14'. This switch is shown In figure 1 . This results in the ES 
finding the clauses binfo("ns4", "LI 14", "load", "sdl 14", "closed"). The ES now recognizes 
that opening sdl 14 interrupts power flow through the Une named LI 14. To determine 
what loads may be de-energlzed the ES needs to determine which loadpaths this line Is a 
member of. Any loadpath with this clause Is no longer valid and must be retracted from 
working memory. The loadpath clauses are of the form 

loadpath(load_name, loadpath_list). The loadpath_list lists the lines forming that 
specific loadpath for the given load. The ES retracts those clauses whose loadpath_list 
contains LI 14 as a member. Any given load which has had all Its loadpath clauses 
invalidated has been de-energized. To signify de-energized loads the ES asserts clauses 
of the form deen(loadname). 

The E)S determines how a branch element fault affects the system in two steps. 
First It determines the switches which must be opened to isolate the fault. Second it 
evaluates the effects of opening the switches. The methodology just reviewed for 
evaluating the effects of opening switches remains unchanged. 

To Isolate the fault the ES begins by checking if the faulted branch element has a 



breaker. This Initial step is accomplished with the rule: 
open the faulted branch's breaker if 

assert that branch element as ooc and ( 1) 

it has a breeiker and (2) 

assert the breaker and branch element as lost and (3) 

retract that breaker as open emd (4) 

determine de-energIzed loads and (5) 

continue isolating fault. (6) 



56 

To fiorther isolate a fault the ES must fan outward from the fault along all possible 
paths. The first switching device along each path becomes the fault boundary for that 
path. To complete this procedure the ES must recognize all the possible branch 
combinations and know how to handle each. Figure 15 Illustrates the five possible 
branch situations. While any type branch— source, hne. or load— may be considered, the 
examples will use line branches for simplicity. 




figure 15: Line S^ment T 3 ^pes 

The blnfo clauses of Interest for figure 15 follow: 

binfo("nl","llneA","none", "closed") binfo("nAl","llneA","sdA","open") 
blnfo("nl","lineB","none","closed") blnfo("n2","lineB","none", "closed") 
blnfo("nl","lineC","sdC","closed") 

binfo("nl","llneD", "none", "closed") binfo("nDl","UneD","sdD","closed") 
binfo("n2","lineE","sdE","open") 

Because the previous rule opens switches adjacent to the fault line, the starting point tn 
isolating any fault will either a type A line, a line with an open switch at one end and no 
switch at the other end, or type B line, a line without switches at either end. To 
illustrate the ES actions, assume a short circuit line fault occurs on line A and that sdA 
was originally closed. The Initial rule just discussed opens sdA, asserts into working 
memory that line A and sdA are lost, and that UneA Is OOC. The ES must now move off 
llneA and determine the remainder of the fault isolation area. This rule Is: 
given nl and line A continue Isolation search If 

there Is another branch connected, to n2 and ( 1) 

that branch has not been considered before and (2) 

using nl and that branch continue Isolation search. (3) 
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The left hand side (Ihs) of the rule establishes the last breinch considered. Lines 1 cind 2 
determine if there is another branch to be searched. Line 3 is a recursive call to cause 
the search to continue from the old node down the new branch. For this example 
assume the ES found line D as the next branch. The rule for this type line is: 



given nl and line D continue isolation search if 

the branch clause is binfo(nl, line D,_, none.closed) and (1) 
there exists the clause blnfo(ndl, line D,_.sdD.closed) cmd (2) 
sdD represents a switching device and (3) 

open sdD. retract sdD closed and (4) 

assert sdD as lost and (5) 

determine de-energized loads and (6) 

fall. (7) 



This rule recognizes that the end of the branch connected to the search node, nl, doesn’t 
have a switch in line (1). The other end of the branch, at nDl, does have a closed switch 
(lines 2&3). Line (4) asserts a clause noting that the switch is opened and retracts the 
clause indicating the switch was closed. Line(7) causes the rule to fail. The fed 
predicate causes the ES to backtrack to nl to continue the search. Using the fad 
predicate conserves stack resources and speeds program execution. The type A rule now 
must find another path, assume line C. The rule for type C branches is: 



given n 1 and line C continue isolation search if 

the branch clause is binfo(nl, line C,_, sdC.closed) and (1) 
sdC represents a switching device and (2) 

open sdC, retract sdC closed and (3) 

assert sdC as lost and (4) 

determine de-energized loads and (5) 

fail. (6) 



In this rule lines 1 &2 Identify the element having a closed switch adjacent to the search 
node. The switch is opened to Isolate the fault. This rule also fads to cause 
backtracking. The LlneA rule next tries line B. The rule for a type B line is: 



given nl and line B continue Isolation search if 

the branch clause is blnfo(nl.ltne B,_,none,closed) and (1) 
there exists the clause blnfo(n2,line B,_,none,closed) and (2) 
assert line is lost and (3) 

there is another branch connected to n2 and (4) 

that branch has not been considered before and (5) 

n2 and that branch continue isolation seeu'ch. (6) 
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This rule moves the search point from one end of the branch to the other. At node n2 



there Is one remaining branch, line E. Its rule; 

given n2 and line E continue isolation search If 

the branch clause Is blnfo(n2.1lne E._,sdE.open) and ( 1) 

sdE represents a switching device and (2) 

assert sdE as lost and (3) 

fall. (4) 



This rule handles the situation of encountering an open switch. The only working 
memoiy adjustment needing to be made is. lost(sdE), Indicating that switch sdE Is lost 
from service. This clause Is Inserted Into working memory so that the ES knows It 
cannot later close this switch as part of a possible load recovery path. This rule also 
falls causing backtracking to check for other branches. 

Through backtracking each node is checked for all branches. Checking aU 
branches at every node Isolates the fault. When the backtracking Is complete each of 
these rules will have failed and control returns to the calling rule. Prolog then looks for 
another version of the calling rule which can be evaluated as true. That version updates 
the distribution line energized list. 

Re-energizing De-energized loads 

Problem Nature. During the analysis of faults the ES inserts Into working 
memory facts indicating ooc switching devices, lines within a fault isolation area, and 
loads de-energized from either a single element fault or from the opening of a breaker. 
To restore power to a de-energized load there must be a path from the load over usable 
lines and through usable switching devices to an energized line. By examining the 
system topology and the status of the system lines and switches leading away from each 
de-energized load the ES cein determine potential restoration paths. In analyzing line 
status the ES checks that the line branch's status Isn't 'lost' and if It Is 'energized.' 'Lost' 
lines cannot be included In restoration paths. When the ES reaches 8in energized line it 
has completed a restoration path. For switching devices, the ES Isn't concerned about 
their positions but only If they are available for servlce—not 'lost.' When the open 
switches are closed the restoration path and the de-energized load become energized. 

User/E^ Interaction. To direct the ES the user gives the command 'restore.' The 
ES first finds a de-energlzed load and teUs the user a restoration path Is being sought for 
that load. If a restoration path is found the ES lists the distribution lines that make up 
the potential loadpath from the load to the energized line. The ES also lists the 
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switching devices for those lines. After the ES finds all possible paths it will print out 
the message ’ no further paths The process repeats Itself until all de-energized loads 
have been checked. When aiU loads have been checked the lists those loads for which 
there were no restoration path. 

Methodology. The ES uses two rules to find restoration paths for de-energized 



loads. These are: 

rule 1: restore with Branch, Path_list, & Swltch_llst if 

current branch is energized and (1) 

assert the restorative Path_llst and Switch_list and (2) 
write the Path_llst and Switch_llst. (3) 

rule 2: restore with Branch, Path_llst, & Swltch_list if 

Branch is not energized and ( 1) 

Node/Branch has not been considered and (2) 

Branch and its switching device are not lost' and (3) 

append its switching device to Switch_llst and (4) 

there is a Branch2 which connects to Branch and (5) 

Node/Branch2 has not been considered and (6) 

Branch2 and its switching device are not 'lost* and (7) 
Branch2 is not a load and (8) 

append Branch2’s switch to Switchjlst and (9) 

append Branch2 to Path_list and (10) 

restore with Branch2, Path_list, & Swltch_llst. (11) 



Rule 1 is the termination rule. When the branch under consideration is an energized 
branch the path is completed (line 1). Line (2) asserts into working memory the 
Path_llst and Switch_llst. Line (3) displays the solution to the user. The solution 
Includes the list of lines and switching devices in the restoration path. AU the lines 
will be unenergIzed except the last line. The list begins at the load and terminates with 
the energized branch. To see if any alternative restoration paths exist, the ES must 
backtrack along the list of uneneigized lines making up the first restoration path. This 
search is done by the ES forcing backtracking through these two rules until no further 
solutions are found. 

Rule 2 does the actual search for candidate lines. When searching to find the 
first solution only lines (2) through (11) are necessary. However, to force backtracking 
after having found a solution path, line (1) is necessary. Line (1) forces the search back 
down the unenergized line list. Lines (5), (6) and (2) jointly select node/branch 
combinations to examine the system topology leading away from a de-energized load. 
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During the first petss through this rule the node/branch pair Is the de-energized load 
and the node that connects the load to the rest of the system. Since this Is the first time 
through the rule, line (2) is satisfied. Line (3) checks that the switching device for this 
node/branch pair can be closed and allow power flow through the branch. The switch is 
appended to the Swltch_llst In line (4). Lines (5) and (6) find a connecting branch which 
hasn’t previously been considered. On the first pass through the rule, Branch2 will be 
the branch which connects to the de-energized load. The found node will be the node In 
common with the de-energized load. Line (5) finds this node/branch pair. Line (6) 
verifies that this pair have not been previously considered. Additionally, to add this 
branch to the restoration list it must not have a ’lost’ switching device, itself be ’lost’, or 
be a load. The ’load’ test prohibits the ES from using a load as a distribution line. Line 
(1 1) is a recursive call with Branch2 as the new line being traveled In search of an 
energized line. The node Is not Included as part of the recursive call. By not including 
the node In the call, line (2) finds the other node associated with Branch2 and so the ES 
can find the next connecting branch. This process continues until rule one is satisfied, 
another restoration path Is fotmd, or all connecting branches have been checked and 
both rules fall. 

Ebcamples best illustrate this process. Many of the more Important loads have 
two feeders to provide power. Figure 14 shows this arrangement for Quarters Group 7. 
Consider the normal positions of sdq7 and sdqTb as open and closed respectively. Also 
assume all of the shown lines are energized. If the user were to issue the command ’open 
sdqTb’ the ES would respond with a statement Indicating quarters group 7 had been de- 
energized. If the user were then to Issue the ’restore’ command the ES would seek all 
restorative paths for this load. The restorative paths are: 

qtrs7 to L216f through sdq7; qtrs7 to L216g through sdq7; qtrs7 to L215d through 
sdqTb; and qtrs7 to L2 15e through sdqTb. Had the user first given the command ’ooc 
sdqTb’, switch sdqTb would be in working memory as a ’lost’ switch. As such rule 2 
would disqualify switch sdqTb from being In the restorative path and only the first two 
responses would still be solutions. 

As a final example consider a modification situation shown in figure 16. 
Assume that LI 14x is being taken out of service for some period of time. The 
distribution system operation procedures require at least two sources of power for every 
load. To provide for this requirement the job plans call for opening sdl 14 and sdlm 
long enough to cut out LI 14x and tie in temporary feeders to LI 15. Currently, the loads 
shown In figure 16 have two sources of power. The normal source Is from subl through 
normalfy closed sdl 14. The backup source is through normally open sdlm. The test 
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proposition states that the temporary feeders wlU assure a slmllcir normal source and 
backup source for the loads of figure 16 when LI 14x Is taken out of service. The user 
needs to modify the DBMS distribution system database in such a way as to represent 
the temporary feeders and to eiUow simulation of the proposed sequence of operations. 
The difficult part is simulating the removal of LI 14x. The 'ooc LI 14x' command can not 
be used because it simulates that LI 14x is shorted and will form a fault isolation area. 
The alternative methods Include taking the line out of the database prior to the ES’s 
Initial S 3 TStem analysis or to Introduce one or more switches in LI 14x to interrupt 
power flow through LI 14x. The later method is chosen as it allows the simulation to 
more closely follow the Job sequence. From the DBMS with the 'modify' command the 
user can change the entries in the BRANCH relation from 

branch(nl.8,L114x,none) and branch(nl.ll,L114x,none) to 
branch(nl.8.Ll 14x,sdt3) and branch(nl. 1 1,L1 14x,sdt4). 

In the BKRPOS add entries showing that sdt3 and sdt4 are closed breakers. When the 
ES's relation prepau^tlon program runs the system description database BINFO will 
show 

bInfo("nl.8"."Ll 14x"."Une","sdt3","closed") and 
blnfo("nl.ll","L114x","line","sdt4","closed") instead of 
bInfo("nl.8","Ll 14x"."llne"."none",”closed") and 
binfoC'nl . 1 1","L1 14x”,"line","none","closed"). 

These modifications change the representation of line LI 14x to Include the closed 
breakers sdt3 and sdt4. The user can then give the commands 'open sdt3' and 'open sdt4' 
in sequence to simulate taking LI 14x out of service. 

Also the user adds similar information to represent the temporary feeders, with 
open switches, between LI 14x and FI 15. With these changes complete the user can move 
to the ES. In the ES. the 'paths' command will begin the initial system analysis. Since 
the LI 14x switches are closed and the temporary feeder switches are open, the results of 
the analysis will be the same normal system operating conditions as before the 
database changes. 

Once the initial system analysis has been completed the user is ready to 
simulate the job plan sequence. The job plan calls for normally open sdlm to be open 
and then to open sdl 14. The ES will respond to the command 'open sdlm' with a 
statement that it Is already open. The command 'open sdl 14' is given next. The ES will 
change the position of sdl 14 in working memory and then determine the affect of 
opening sdl 14. The determination will result in the loads being listed as de-energized. 
The command 'ooc LI 14x' will cause the ES to consider line LI 14x as having a fault. 
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This will open sdt3 and sdt4. LI 14x along with sdt3 and sdt4 will be placed In working 
memory as lost. 

With the command 'restore' the ES begins finding the restorative paths. For 
each of B1304, B6019, and B6015 the ES finds two possible paths. The first through 
sdlm to Lspld which is energized. The second through the lower temporary feeder. LT2, 
and switching device SDNTl adjacent to node nt2 to FI 15 which Is also energized. The 
remaining loads which were lost when sdl 14 was opened also have two restorative 
paths. The first would be their normal loadpaths through sdl 14. The alternative would 
be through the upper temporary feeder, LTl, and the switching device SDNTl adjacent 
node ntl to FI 15. 

From these results a S 5 rstem manager could determine that by closing sdl 14 and 
sdlm the figure 16 loads would be energized. The temporary feeders, LTl and LT2, would 
serve as an alternative power source when switches SDNTl and SDNT2 were closed. 

The previous ES example steps are listed with their execution times in table 10. 



Table 10. Example Executloii Times 



step 

relation preparation program 
paths 

energized lines 
open sdl 14 
energized lines 
ooc 1114x 
energbsed lines 
restore 



execution time 

1 minute 40 seconds 

40 seconds 
58 seconds 
3 seconds 
58 seconds 
1 second 
58 seconds 
39 seconds 



This chapter shows how the and DBMS can jointly be used as an effective 
engineering aid. The ES contains the rules or methods for solving connectivity 
problems on an electrical distribution ^stem. The DBMS serves as the source for the 
system specific information. The DBMS also allows the user to modify the nature of the 
system information by changing both switching positions and system topology. 

In addition to being able to correctly solve connectivity problems the ES 
offers the additional advantage of not overlooking Information thereby avoiding 
missed solutions. The is also fast. Initial system analysis of loadpaths and 
energized branches takes only 40 and 58 seconds respectively. 
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Chapter IV: Conclusions 



This project has investigated and demonstrated an electrical distribution 
^stem engineering aid consisting of an ES supplemented by a DBMS. The DBMS serves 
as an information manager. It provides for distribution system information 
collection, storage, manipulation, and retrieval. The ES assists distribution system 
managers In solving distribution system connectivity problems. The ES contains the 
reasoning rules for problem solving and links with the DBMS distribution system 
database for Information which specifically describes the Bangor Submarine Base 
distribution system. 

The ES/DBMS approach demonstrates that Information can be managed 
separately from the ES. This approach provides several benefits. By maintaining the 
information separately the user benefits from the data management strengths of a 
DBMS discussed in Chapter 2. For the ES user these include: (1) reduced data gathering 
costs due to central Information management and (2) information consistency and 
Integrity as a result of central management using FNF relations. The ES need not 
bother with as many data manipulation functions. This would take advantage of the 
DBMS which is written to optimize these type of operations. By shedding the data base 
management tasks the speed of the ES would Improve. 

Also, with the ES/DBMS approach the ES stands Independently from the 
Information. The same ES can be used at different sites without modification. The 
consistency of ES code between different sites would ease code upgrade. Using this 
approach, these traits would hasten the development and Improvement of ESs. 

Concerning the ES. Human users with a variety of experience currently analyze 
distribution systems to solve connectivity related problems. The human methods can 
be encoded using Prolog into conditional 'tf-then' rules to allow an ES program 
reproduce human reasoning. Just as different correct humem methods require different 
amoimts of effort to reach a solution, ES rules need to be carefully composed for 
efiiclent execution. In part this Involves not having redundant subgoals in the RHS of a 
rule. If the ES has already checked a fact once, checking It unnecessarily a second time 
slows down execution. Backtracking is a useful tool for finding alternative solutions, 
however, tneflicient backtracking is also slow. Rules which had subgoals added to 
cause efficient backtracking showed significant execution Improvements. 

Rule based EiSs can easily be expanded and modified. The first version of the ES 
considered only single branch element line failures. The inclusion of load and source 
elements failures was completed without the addition of any rules. It was noticed that 
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generalizing the existing rules automatically accommodated load and source failures. 
Since Prolog programming emphasizes Individual rules the overall program structure 
was not Impacted. By allowing the ES user to move to the DBMS to make database 
chcuiges without exiting the ES, this project showed that the DBMS can exist In RAM 
and operate without disrupting the ES. 

Concerning the DBMS. The goal In writing a DBMS In Prolog was not to write 
the ultimate DBMS. The DBMS did Illustrate the principles of relational model 
database management. The performance measurements Indicate that Indexing 
schemes such as B-trees are necessary for Prolog coded DBMSs to be acceptably fast. 

Linking the ES and DBMS. The relation preparation program used In this thesis 
demonstrated that the ES can accept Information from a DBMS. The approach taken 
transfers all the Information Into the ES at once. A better approach would allow for 
querying the DBMS for specific Information and then transferring that information 
Into the ES’s working memory. Appendix A discusses other linking approaches . 

Limitations and Extensions Each of the three programs developed as part of 
this thesis— the DBMS, the ES, and the relation preparation program— seemed quite 
adequate when they were first conceived. After they were developed and used together 
limitations and desired enhancements became obvious. Some of these, speed 
enhancements and generalization of the single fault analysis rules, were Incorporated 
into the program code. Others either require more work than time was available for or 
their Implementation was not apparent. 

The biggest problem with the DBMS Is its performeince. Without some indexing 
scheme the DBMS manipulations are excessively slow. 

The ES demonstrates basic cormectlvlty aneilysls. Currently the substations are 
viewed as power sources. A more correct view would be to consider the BPA feeder and 
any active generators as power sources to the substations. This Is not a difficult 
extension as It would require only minor rule modifications. Because the ES views the 
substations as sources, faults In the 1 15 kv ring can not be modeled. The ES single fault 
analysis finds the closest switches which can isolate a fault. An enhancement would 
also take Into account the automatic actions of breakers. This would provide for 
determining what should be the automatic response of the ^stem as well as the 
minimum area to Isolate a fault. An enhancement to the restoration rules would 
include further direction as to what switches are currently open and need to be closed 
and the sequence for closing the switches. As Appendix A discusses, a more 
generalized link between the ES and DBMS would allow the ES to take advantage of the 
DBMS Information management strengths. 
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Appendix A: Prolog DBMS Links 



For the typical ES both the rules and problem facts are part of the program code. 
The rules and facts establish what the program knows at program execution. The user 
queries the ES to start Its solution mechanism. The ES examines facts and rules 
drawing Inferences, asserting new facts, and retracting facts to reach a solution. When 
the inference engine Is trying to match a proposed fact against the known facts, the 
program starts at the first clause fact and works Its way down the clause fact list until 
the match is achieved. For large amounts of data this sequential search Is relatively 
slow. 

This project maintains that the ES rules and problem Information should be 
maintained separately. Several factors support this position. Beyond the arguments 
that Information should be centrally collected and managed, not all problem facts are 
static In nature. A DBMS based database easily accommodates the need to change 
information concerning a problem. ESs are not as efiTlclent as DBMSs for data 
manlpialatlon. Commercial DBMSs use Indexing schemes to reduce data search effort 
and Improve performance. Linking with a DBMS could provide rapid retrieval of 
Information required by the ES. As well as being fast in directly looking up 
Information the DBMS rapidly performs relational operations. An Ideal ES/DBMS 
link would allow the storage of problem Information outside RAM. The ES could then 
access much more Information than It could If all problem facts had to always reside In 
RAM. The ES could also store new Inferred facts off line as DBMS relations. There Is no 
question of merit In Unking a DBMS to an ES but rather only of methodology. 

The relation preparation program used In this project takes advantage of some 
of these arguments. This approach does not, however, provide a general Information 
linkage between the ES and the DBMS. Brief discussions of more general potential 
methods of Unking ESs and DBMSs together follow. The alternatives considered are: 

1) direct access to a DBMS datafiles with data manipulation by the ES; 

2) Unking to a DBMS with progreun or command files: 

3) Incorporating DBMS procedures within the ES. 
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Accessing the DBMS Datafiles 

Accessing of DBMS datafiles means the ES can read the DBMS's Information 
from its datafiles. Use of the DBMS datafile accommodates the Issues of expanding the 
facts available to the ES beyond the RAM capacity and the consideration that data is 
not always time Invariant. 

Commercial DBMSs such Rbase 5000 & dBaselll encode a description of the 
datafile structure. Properly reading this description reveals the structure of datafile. 
Both applications store data as a mixed binary /ASCII file. The datafile can be 
sequentially read eind, as desired, the variables bound as ES fact statements. By storing 
and retrieving data in this manner RAM is used only for the data germane to the current 
problem solution. This sequentially reading of data while as efficient as the process 
used by Prolog, falls to take advantage of the more efficient Index based retrieval used 
by DBMS. While the original benefits of non-RAM data storage still exists, execution 
time Is Increased as reading Information from a disc file is slower than RAM access. 

Access to data could be Improved if the Indexfile could be interpreted. Using the 
indexfile would allow more direct and faster access to the information. However, as the 
DBMS manufacturers considered information the IndexfUe’s construction proprletciry, 
its structure is not readily available. E>en if the indexfile could be read this approach 
would probably still be a 'read-only' approach. Without the ability to update the 
indexfile one could not write information to the DBMS. Also this method does not 
provide for relational manipulations. 

Linking via a File 

Commercial DBMSs provide for interactive data manipulation at the prompt 
level. In this mode the user Issues a specific commemd and the ^stem complies with it. 
By using a text editor to develop a list of commands the user can develop a program file 
of commands for the DBMS to execute. It seems reasonable that Prolog could generate a 
command file such that procedures could be run or more specific searches could be made 
of datafiles. Prolog does provide a command for invoking DOS commands. So 
conceptually, Prolog generates a command file then Invokes the DBMS to run the file. 
Prolog allows for the DOS command to Invoke the DBMS, the DBMS performs whatever 
data manipulation is required, an output file is generated, program control returns to 
the ES. eind the ES reads in the file. System performance may be acceptable through the 
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use of hard disks and RAM disks. This approach remains RAM intensive and does not 
provide for moving ES Inferred facts into the DBMS. 

Incorporating DBMS Procedures 

Incorporating DBMS procedures in an ES Involves taking the code from a full 
featured DBMS and incorporating whose desired portions into the ES code. This 
technique is typified by the Program Interface, PI, product for Rbase 5000. The PI code 
package Is a set of DBMS routines which are linkable to Microsoft Pascal, C, and 
FORTRAN programs. 

With this technique a Pascal, C, or FORTRAN program is written which takes 
advantage of the DBMS file PI procedures. The PI product once incorporated into the 
application program no longer requires the Rbase 5000 program code. All that Is 
required is that the database exists. It works directly with the database files. 

As Prolog claims it could incorporate procedures written in .OBJ compilable 
Pascal, C, and FORTRAN, this approach was examined. After achieving onfy limited 
success, Borland technical representatives were consulted. They indicated that ’simple’ 
procedure calls were indeed supported. However, as each implementation of higher 
level languages handled compilation differently, complex calls would not likely work. 
Borland has announced a fully compatible version of C that was developed with the Idea 
of being able to fuUy link with Borland Prolog. If a version of the Program Interface 
were made available that was compatible with Borland C It could be linked to a Prolog 
based ES. Should DBMS features be Incorporated into the ES, most of the advantages of 
the DBMS would be realized. 



A{>pendix B: System Requirements 



The DMBS, ES, and relation preparation programs are all Implemented In 
Borland Turbo Prolog. Borleind Indicates the minimum system requirements to use 
Turbo Prolog as: 

IBM PC or compatible computer; 

384KRAM: 

PC-DOS or MS-DOS operating system, version 2.0 or later. 

Prolog allows program code to be compiled directly to memory while working In the 
Prolog language. Because of the Prolog system code residing In RAM at the same time 
the compiled program code resides in RAM. 640K RAM and a hard disk are necessary to 
allow working with reasonably large databases. 

However. Borland Prolog also allows the generation of stand alone programs. 

To run the complied programs the Borlemd Turbo Prolog product Is not necessary. The 
DBMS Is the largest application developed as part of this project. The DBMS code, the 
MSDOS. and stack overhead requires approximately 200K. Memory greater than this Is 
available for relation storage and manipulation. 

The ES and the DBMS programs as well as all files must reside In the same 
directory. The user activates either program by typing that program's name. 



Appendix C : DBMS Command Summary 



select 'relation name' 
help 

enter ('relation name') 
new 'relation name' 
view select ('relation name') 
view all ('relation name') 
modify ('relation name') 

-global change with no prompting 
-global change with prompting 
-delete records, no prompting 
-individual record changes 
project 'existing relation name' 'new relation name' 
join ' existing relation name' 'existing relation name' 'new relation neune' 
dir 
erase 
info 
clock 
quit 



(...) Indicates optional command 
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